先说表结构设计这块，真是血泪教训。最开始图省事，把用户订单和订单详情揉在同一张表里，结果数据量刚上十万查询就慢成狗。后来拆分成两个表，用order_id做外键关联，查询效率立马提升三倍不止。这里有个细节，订单表里的create_time字段开始用的timestamp，后来发现跨时区同步数据会出乱子，赶紧改成datetime类型。索引这块也是坑，最开始就给主键建了索引，后来发现经常要根据用户ID查订单，又补了个普通索引。最要命的是有个二货在状态字段上建索引，那字段就0和1两种值，索引根本没用还拖慢写入速度。
SQL优化这块水更深。刚开始写的语句各种子查询嵌套，后来被DBA骂得狗血淋头。比如统计用户订单数量的查询，原来要5秒才能跑出来，改成JOIN查询后直接降到0.3秒。还有一次遇到个神奇的问题，某个查询偶尔会超时，后来发现是字符集不一致导致的全表扫描。这里特别提醒，utf8和utf8mb4混用会导致索引失效，血的教训啊！
事务处理这块也是个雷区。有个资金结算的功能，开始没加事务控制，结果服务器突然重启导致数据不一致，对账对到凌晨三点。后来全部改成事务操作，关键业务还加了重试机制。不过事务也不是万能的，遇到死锁就更头疼了。有次两个用户同时修改同个订单，直接就死锁了。最后只好调整业务逻辑，把更新顺序统一规范起来。
备份方案我们折腾了好几个版本。开始用mysqldump全量备份，后来数据量大到备份要两小时，改成主从复制+增量备份。有次从库同步延迟太严重，差点导致报表数据出错。现在我们的方案是每天凌晨全量备份，每小时binlog增量备份，重要业务数据还要实时同步到备库。
遇到最诡异的一次是CPU突然跑满，查了半天发现是某个临时报表的SQL没加时间限制，直接全表扫描了。后来我们定了规矩，所有查询都必须带时间范围，大表查询必须走索引。还有一次内存泄漏，show processlist查不出问题，最后发现是连接池配置不对，连接数超过max_connections了。
这个项目让我明白，MySQL看着简单，真要玩转还得下功夫。现在我们的系统支撑着每天几十万订单，虽然偶尔还会出点小毛病，但整体还算稳定。最近在研究分库分表方案，等搞完了再来分享经验。大家在MySQL项目里还遇到过哪些坑？欢迎评论区交流！
（注：本文仅代表个人项目经验，具体实施方案请根据实际业务场景调整）