MySQL性能提升那些事儿，实用技巧和经验分享帮你数据库跑得更快

说到MySQL怎么才能跑得更快,这事儿其实没那么玄乎，关键就是别让数据库“干累活儿”，它就像个仓库管理员，你老让它全仓库翻箱倒柜，它肯定慢，我们的目标就是让它多走索引这条“高速公路”，少干“扫地式”的全表扫描这种苦力活。

第一招，给查询语句加上“GPS”——索引。

索引是提升查询速度最立竿见影的方法,但索引不是乱加的，加多了反而会影响写入速度（因为每次插入、更新数据都得维护索引），要加在刀刃上。

• 口诀是：查谁就建谁。 我们经常用WHERE条件来筛选数据，比如WHERE user_id = 100，那就在user_id这个字段上建索引，经常用ORDER BY排序，比如ORDER BY create_time DESC，那create_time也是个建索引的好候选。
• 联合索引要讲究“最左前缀”原则。 这名字听着唬人，其实很简单，比如你建了一个联合索引是 (city, age, salary)，它的效果是这样的：
  • 查询条件用WHERE city='北京'，这个索引能用上，好比你知道要去北京市找。
  • 查询条件用WHERE city='北京' AND age=30，索引也能用上，更精确了，去北京市找30岁的人。
  • 但如果你直接用WHERE age=30，这个索引就用不上了！因为它就像GPS必须先输入城市（最左边的条件），你直接说找30岁的人，它不知道去哪个城市找，只能全表扫描，这个原则非常重要，很多慢查询都是因为它。（来源：常见的MySQL索引优化知识）
• 避免在索引列上做计算或函数操作。 比如WHERE YEAR(create_time) = 2023，即使create_time有索引，也因为用了YEAR()函数而导致索引失效，应该写成WHERE create_time BETWEEN '2023-01-01' AND '2023-12-31'。

第二招，学会“拆”和“预加工”——查询语句的优化。

很多时候,慢不是数据库的锅，而是我们写的SQL语句太“笨”了。

• 只取需要的数据。 坚决避免SELECT *，它会把所有字段的数据都捞出来，网络传输和数据库解析都是负担，你需要什么字段，就明确写出来，比如SELECT id, name, email。
• 学会用连接（JOIN）代替子查询。 不是绝对的，但很多时候，一个良好的JOIN查询会比一个嵌套很深的子查询效率高得多，因为子查询可能会被重复执行多次，而JOIN的方式更集合化。（来源：SQL优化实践经验）
• 警惕大分页查询。 LIMIT 1000000, 20这种查询是非常可怕的，它意味着MySQL要先扫描并丢弃前100万条记录，然后才返回最后的20条，对于深度分页，可以用“延迟关联”来优化，比如先通过索引查到需要的主键ID，再根据ID去取数据，而不是直接偏移量巨大地扫描。
• 批量操作代替循环单条操作。 在程序里，如果要插入多行数据，用INSERT INTO table VALUES (a,b,c), (d,e,f), ...这样的批量语句，远比在循环里一次次执行INSERT要快得多，因为它大大减少了网络交互和SQL解析的次数。

第三招，从设计上就打好基础——表结构设计。

如果表结构设计得不好,后面再怎么优化索引和SQL都事倍功半。

• 选择合适的数据类型。 能用INT就别用VARCHAR来存数字；字符串字段长度够用就行，别动不动就VARCHAR(255)；尽量使用NOT NULL约束并设置默认值，因为NULL值会让索引和计算变得更复杂。
• 范式化和反范式化的权衡。 数据库理论教我们要范式化以减少数据冗余，但在大流量、高并发的互联网应用中，为了追求极致的查询速度，可以适当牺牲一些范式规则，允许少量的数据冗余（反范式化），在一张订单表里，除了存用户ID，直接把用户名也存一份，这样查订单的时候就不用再去连用户表查名字了，这叫“用空间换时间”。（来源：高性能MySQL设计原则）

第四招，日常维护不能少。

数据库就像汽车,需要定期保养。

• 定期分析慢查询日志。 MySQL可以设置一个阈值（比如1秒），执行时间超过这个阈值的SQL都会被记录下来，定期检查这个日志，把里面的“慢查询”抓出来优化掉，是性能调优的核心工作。
• 关注硬件和配置。 如果数据量真的大了，升级硬件（比如用SSD硬盘）是最简单粗暴的提升方式，MySQL本身有很多配置参数，比如缓冲池大小innodb_buffer_pool_size，这个值设置得太小，数据库就不得不频繁在内存和磁盘之间倒腾数据，肯定会慢，通常建议设置为可用内存的70%-80%。（来源：MySQL官方文档关于缓冲池的配置建议）

MySQL性能优化是一个持续的过程,不是一个一劳永逸的动作，核心思想就是：建立有效的索引，编写高效的SQL，设计合理的表结构，并辅以定期的监控和维护。 从这些实实在在的地方入手，你的数据库就能轻松不少。