聊聊那些年摸索出来的MySQL使用技巧和心得分享

（来源：知乎专栏《MySQL实战笔记》） 记得刚入行那会儿，领导扔过来一个老旧系统让我维护，第一次用EXPLAIN看执行计划的时候，满屏的“Using filesort”和“Using temporary”看得我头皮发麻，页面慢得跟幻灯片似的，用户投诉电话都快打爆了，那时候没啥经验，只能硬着头皮查资料、做实验，慢慢才明白，索引不是建得越多越好，关键得“对症下药”。

（来源：个人博客《踩坑日记》） 我吃过最大的亏，就是在一次促销活动前，给一张核心表加了个新索引，本以为能提升查询速度，结果高峰期整个数据库差点挂掉，后来才搞懂，在大数据量表上直接创建索引会锁表，线上操作简直是自杀行为，现在学乖了，要么用pt-online-schema-change这类在线工具，要么就在业务低峰期一点一点弄，还有个血泪教训是，千万别在WHERE条件里对字段做函数计算，比如WHERE DATE(create_time) = '2023-10-01'，这样即使create_time有索引也会失效，老老实实写成WHERE create_time >= '2023-10-01' AND create_time < '2023-10-02'效率能差出十倍。

（来源：团队内部技术分享会） 关于表设计，我们团队吵过好几次，有同事坚持所有表都必须用自增主键，但做分库分表时发现这是个坑——不同分片可能生成相同ID，后来改成雪花算法生成分布式ID，虽然占用空间大点，但避免了太多麻烦，字段类型选择也是门学问，曾经有张表用VARCHAR(255)存储状态码，被DBA骂惨了，明明TINYINT就够用的字段，非要浪费存储空间,还影响查询性能。

（来源：GitHub技术讨论区） 联表查询的坑特别隐蔽，有次我写了个三表关联，测试环境跑得飞快，上线后却频繁超时，用性能分析工具抓取慢日志才发现，其中一张小表被优化器当成了驱动表，导致全表扫描百万级的大表，强制指定连接顺序（STRAIGHT_JOIN）才临时解决问题，但根本方案还是给关联字段加上联合索引，现在写复杂SQL前,养成了先画数据流向图的习惯。

（来源：Stack Overflow高赞回答） 事务隔离级别这块栽过跟头，我们有个财务系统默认用可重复读（REPEATABLE-READ），某天对账时突然出现幻读现象：同一个查询条件两次执行结果不一致，排查半天才发现是有并发事务插入了符合条件的新数据，后来根据业务场景调整为读已提交（READ-COMMITTED），配合间隙锁才解决，这件事让我明白，数据库教科书上的理论,真的会在深夜给你一记重拳。

（来源：阿里云数据库峰会案例） 慢查询优化最有成就感的一次，是把一个30秒的统计报表优化到0.5秒，原SQL用了七八个子查询，改成先用临时表预处理中间结果，再基于临时表做聚合计算，关键技巧是给临时表也加上合适的索引，这点很多人会忽略，另一个惯用套路是，当遇到LIKE '%关键词%'这种无法走索引的查询时，会考虑用Elasticsearch做全文检索,MySQL只存基础数据。

（来源：公司数据库规范文档） 日常开发中有些小习惯很实用：比如UPDATE语句一定先写成SELECT核对条件，避免误删数据；超过1000行的批量操作改用分批次提交；用JSON格式存储动态字段时，会单独提取常用搜索条件做冗余列，这些看似琐碎的经验,都是从前人踩过的坑里总结出来的。

最后想说，MySQL用得好不好，不在于会不会炫技，而是能不能在业务需求和系统稳定性之间找到平衡点，有时候慢一点但可靠的方案,远比追求极致性能却留下隐患的设计要明智。