一、 前言为什么要做MySQL优化在应用开发过程中数据库的优化往往能带来数倍甚至数十倍的性能提升。日常工作中我们遇到的性能问题大部分都源于SQL语句编写不当导致索引失效。数据库架构单一单点故障并发支撑不足。数据量过大单表查询缓慢。针对这些问题我们需要从SQL执行层和数据库架构层双管齐下进行改造。二、 SQL优化实战Explain解读在MySQL中EXPLAIN命令是分析SQL性能的核心工具。通过查看key实际使用的索引、type访问类型如ALL全表扫描、ref引用、range范围、key_len索引长度等字段我们可以一眼看穿SQL的执行效率。以下是我们基于实际案例总结出的7大索引使用黄金法则1. 尽量全值匹配最左前缀原则的根基规则建立联合索引idx_staffs_nameAgePos(name, age, pos) 后查询条件应尽量与索引的顺序完全匹配。实战演示WHERE nameJuly命中索引 (key_len74)。WHERE nameJuly AND age25命中索引且使用了更长的索引长度 (key_len78)。WHERE nameJuly AND age25 AND posdev全值匹配索引利用率最高 (key_len140)。结论查询条件的组合越靠近索引定义的顺序效率越高。2. 最佳左前缀法则带头大哥不能死规则联合索引的最左列必须出现在查询条件中且不能跳过中间的列。失效场景如果我们查询age 25 AND pos dev跳过了name或者只查posdev那么分析结果会是typeALL全表扫描索引彻底失效。结论查询从索引的最左前列开始且不跳过索引中的列。3. 不在索引列上做任何操作破坏原子性规则不要在索引列上使用函数如left,substring、计算甚至隐式类型转换这将导致索引失效转为全表扫描。失效案例WHERE left(name,4) July即使用到索引列但由于加了函数Explain显示typeALL。隐式转换陷阱WHERE name 917这里name是字符串但条件传了数字MySQL会触发隐式转换索引失效变成全表扫描。结论保持索引列的纯净MySQL分析器才能走索引树查找。4. 范围条件放最后索引贡献度递减规则在联合索引中一旦出现范围查询,,BETWEEN,LIKE abc%该列之后的索引列将失效。原因索引树是按顺序排列的比如查询namez3 AND age22 AND posmanager由于age是范围导致age排序完了之后pos可能出现在任何一个分支上无法继续利用索引定位。应对key_len会停留在范围条件那列。在设计复合索引时尽量把等值查询的列放在前面范围查询的列放在最后面。5. 覆盖索引尽量用回表问题规则尽量只查询索引中包含的列避免使用SELECT *。实战当查询条件为namez3 AND age22如果直接SELECT *MySQL在索引树找到对应的主键值后还需要回到聚簇索引上“回表”查找其他列数据。优化如果只查询SELECT name, age, posExplain中的Extra字段会显示Using index。结论覆盖索引能显著减少磁盘I/O是提升查询速度的利器。6. 不等于要慎用放弃走索引规则在使用!或者的时候由于无法利用索引树的B树快速查找非等值或非范围MySQL优化器通常会选择全表扫描typeALL。注除非数据量极小或者分布极端否则不建议对索引列使用不等于。7. Like查询要当心左模糊陷阱规则%通配符在左侧如%July时索引失效变全表扫描。在右侧如July%或两侧但结合覆盖索引有可能走索引。解决右模糊/中间模糊的优化如果查询是LIKE %July%通常只能靠覆盖索引勉强优化或者引入ElasticSearch等搜索引擎来替代。实际生产中我们可以把业务查询由左模糊改为右模糊LIKE July%这样就会走range类型的扫描。8. 字符类型加引号类型不一致规则字符串字段必须加单引号。如果不加MySQL会进行类型转换导致索引失效。前面第3点已提及细节重提。结果typeALL相当危险的操作。9. OR 改 UNION 效率更高规则使用OR查询时由于无法有效利用索引合并往往导致全表扫描。优化方案尽量改为UNION或者UNION ALL前提是业务需求允许。举例WHERE nameJuly OR namez3改成SELECT ... WHERE nameJuly UNION SELECT ... WHERE namez3可以分别走两次独立索引查询效率更高。三、 MySQL 架构层面的全局优化当SQL语句优化到了极致然而数据库响应依然缓慢时我们就需要挑战硬件和架构本身了。1. 提升硬件与并发配置硬件升级CPU、更换固态硬盘SSD、增加内存增大innodb_buffer_pool_size。连接数调整通过show VARIABLES like %max_connections%;查看当前最大连接数如图中151。如果并发过高应适当调大这个参数如调至 1000否则客户端将直接报错“连接超时”。2. 引入应用缓存Redis架构图客户端 → 应用服务器 → Redis缓存 → MySQL数据库 → 磁盘IO。作用命中率极高的查询如热销商品、用户信息不应直接透穿到 MySQL。引入Redis后内存级读取能将响应时间从几十毫秒缩短至微秒级同时大幅降低对MySQL主库的访问压力。3. 主从复制 读写分离原理单节点的MySQL面临“单点故障”和“读写争抢”的难题。利用主从复制Master-Slave我们可以构建集群。Master主库专门负责写操作Insert/Update/Delete。Slave从库通过I/O Thread读取主库的Binary Log并写入本地Relay Log再由SQL Thread执行来同步数据。从库专门负责读操作。优势能够分摊压力实现读写分离。主库挂了可以迅速切换从库保障高可用。4. 海量数据下的分库分表策略当数据表达到千万甚至亿级别时即使再完美的SQL和架构也无法支撑。此时必须进入分库分表阶段。阶段一垂直分库按业务拆分场景一个库中既有用户表又有合同表、放款表、风控表。如果所有业务在一个库硬盘I/O和锁竞争极严重。做法将不同业务模块拆分到独立的数据库中。例如客户数据库、合同数据库、放款数据库、风控数据库。优势隔离了业务降低耦合度单库压力瞬间减小。阶段二水平分库分表按数据分片场景即使是“客户数据库”每天有千万级新注册数据单表已无法支撑。做法在同一个业务库的基础上横向拆分数据。采用哈希Hash或取模算法把数据打散到DB1,DB2...DBn的表中。细节分库数据分散在不同的物理节点上。分表数据分散在同一物理节点的不同表里如user_0,user_1。痛点与应对分库分表后跨库JOIN会变得极其困难。通常采取字段冗余在A表中冗余B表的关键字段或者在应用层聚合来解决不能过度依赖数据库的 JOIN 功能。四、 总结MySQL的优化是一套组合拳。第一步优先利用EXPLAIN规范SQL编写严控索引的失效场景最左前缀、不破坏索引列、避免左模糊等。第二步缓存引入 Redis 等缓存层扛住高频读请求护住数据库。第三步架构搭建主从集群实现读写分离解决单点故障。第四步终极当数据量爆炸实施垂直与水平分库分表策略从物理层面解耦。