合理使用索引是关键
数据库查询变慢，很多时候是因为执行了全表扫描。比如你在一个有几十万条记录的订单表里查某个用户的订单，没加索引的情况下，数据库就得一条一条翻，跟在仓库里找一件货一样费劲。这时候给 user_id 字段加上索引，查询速度往往能从几秒降到毫秒级。
别在索引字段上做计算
即使加了索引，写法不对也白搭。比如有张日志表按时间分区，date_time 上建了索引，但有人写成 WHERE YEAR(date_time) = 2024，这样数据库没法用索引，只能全表扫。正确做法是：
WHERE date_time >= '2024-01-01' AND date_time < '2025-01-01'注意复合索引的顺序
多个条件查询时，复合索引的字段顺序很重要。比如经常按 status 和 create_time 查数据，那应该把更常用来过滤的字段放前面。如果索引是 (status, create_time)，下面这条能走索引：
SELECT * FROM orders WHERE status = 'paid' AND create_time > '2024-06-01';但如果只查 create_time，这个复合索引就用不上了。
少用 LIKE '%xx' 开头的模糊查询
LIKE 后面以通配符开头，比如 '%张三'，索引就失效了。就像电话簿按姓名拼音排，你要找“名字最后一个字是三的人”，那这本簿子的排序就没用了。能写成 '张%' 的尽量这么写，这样还能走索引。
避免 SELECT *，只取需要的字段
有时候虽然没全表扫描，但 SELECT * 会把所有列都拉出来，尤其是有大文本字段时，IO 开销大。明确写出要用的字段，既能减少传输量，也能利用覆盖索引直接从索引中取数据。
定期检查执行计划
用 EXPLAIN 看下 SQL 的执行路径，type 列如果是 ALL，那就是全表扫描了。通过 key 列确认有没有命中索引，rows 列看预估扫描行数。发现异常及时调整语句或索引结构。
数据量大时考虑分表或分区
单表数据上千万后，即便有索引也可能慢。可以按时间或用户 ID 做水平拆分，比如每个月的数据放到单独的表里。查最近一个月订单时，直接查对应的月表，自然避开其他数据。