MySQL数据库应用案例教程

去年帮一家连锁餐饮做数据迁移，据库教程他们原先用Excel记录各门店的应用日销数据，财务月底汇总时经常对不上账。案例后来换成MySQL，据库教程建了张sales表，应用字段包括store_id、案例product_id、据库教程quantity、应用sale_date。案例就这么一个简单改动，据库教程财务对账时间从三天压到两小时。应用问题不在Excel本身，案例而是据库教程多人同时改一个文件时，版本冲突根本没法追责。应用MySQL的案例行级锁和事务机制，恰好卡住了这个痛点。

建表时有个细节容易被忽略：字符集。很多教程默认用utf8，但utf8在MySQL里最多只存3字节，遇到emoji或者某些生僻汉字直接报错。用utf8mb4才稳妥。我见过一个电商项目，用户昵称里带了个“𠮷”字，入库时整个订单流程崩掉，排查半天才发现是字符集问题。改表语句不复杂：ALTER TABLE users CONVERT TO CHARACTER SET utf8mb4;，但事先没设计好，后期改起来数据量大了很折腾。

索引是另一个分水岭。有次优化一个查询，订单表500万行，按用户手机号查历史订单，没索引时跑了11秒。加了个普通索引：CREATE INDEX idx_phone ON orders(phone);，直接降到0.03秒。但索引不是越多越好。一个日志表加了6个索引，写入速度慢得像蜗牛。后来砍到2个，写入吞吐量翻了四倍。经验是：频繁写入的表，索引控制在3个以内；读多写少的表，该加就加。

事务的坑更隐蔽。银行转账那种经典案例——A扣100，B加100，两条UPDATE必须在一个事务里。MySQL默认autocommit是开的，每条SQL自动提交。要手动控制得先BEGIN;，再执行，最后COMMIT;。有次开发忘了COMMIT，数据没落盘，测试环境跑得好好的，上线后用户充值记录全丢了。后来查binlog才发现问题。所以生产环境一定要确认autocommit状态，或者干脆用Spring的@Transactional注解来管。

备份策略也得说清楚。mysqldump适合小库，几十G的库用xtrabackup更靠谱。我见过一个创业公司，每天凌晨3点用mysqldump全量备份，结果某天磁盘满了，备份文件写了一半就停了，没人发现。等数据库真挂了，恢复时才发现备份是坏的。后来改成：每天全量+每小时binlog增量，备份完自动校验文件完整性，发邮件通知。这套组合拳下来，RPO能控制在1小时内。

权限管理常被当成小事。开发人员图方便，直接给root账号连生产库。某次一个实习生执行了DELETE FROM orders WHERE 1=1;，忘了加LIMIT，整张表清空。幸好有binlog，回滚了半小时数据。正确的做法是：应用连库用单独账号，只给SELECT/INSERT/UPDATE/DELETE权限；DDL操作走运维流程；每个账号限定来源IP。MySQL 8.0的role功能可以批量管理权限，比5.7方便不少。

最后提一嘴慢查询日志。开启slow_query_log，设long_query_time=1，跑一天后拿mysqldumpslow分析。有次发现一个报表查询没走索引，全表扫描了800万行。加了个复合索引(status, created_at)，直接从12秒降到0.5秒。慢查询日志不会自己告诉你哪里有问题，但它是唯一能让你看到“数据库在喊疼”的地方。

MySQL不难，难的是把每个细节都踩一遍。上面这些坑，踩过的人自然懂。