共计 341 个字符，预计需要花费 1 分钟才能阅读完成。
前言
查问优化、索引优化、库表构造优化须要齐头并进，一个不落。
最佳实际
是否在检索大量的数据行
大多数的慢查问都是因为检索了大量的数据行导致的。
每次看到 select * 时都应该有狐疑扫视的眼光
1. 不必要的列可能导致过多的 IO/CPU/ 内存耗费。
2. 无奈应用笼罩索引晋升性能。
不要反复执行雷同的查问
例如用户头像 URL，该当在首次查问后缓存起来。
查看 3 个指标
- 响应工夫
- 扫描的行数
- 返回的行数
响应工夫 = 服务工夫 + 排队工夫。
服务工夫是指数据库解决查问时真正花了多少工夫，排队工夫是指服务器因为期待某个资源而没能真正执行查问的工夫，如期待 IO 实现，期待行锁等。
抉择一个简单查问还是多个简略查问
切分查问
删除旧数据就是一个很好的例子。
有时候，将多个 join 查问拆分成屡次单表查问更无效。
了解查问背地的工作原理
正文完
