MySQL查询优化：未用主键致Patients表全表扫描性能问题

首先，咱们得先搞清楚为啥明明建了索引，MySQL还是揪着Patients表全扫不放。13000条数据其实不算特别大，但作为大型查询的组成部分，全表扫描的开销累积起来确实会拖垮整体性能，下面是一步步的排查和优化思路：

1. 先把你的查询语句亮出来（脱敏也没关系） #

MySQL优化器选执行计划的核心是看查询的过滤条件、关联逻辑。比如你是不是在Patients表的字段上用了函数操作（比如DATE(p.RegDate) = '2024-05-20'）？这种操作会直接让索引失效；或者关联条件的字段类型不匹配（比如Transactions.PatientID是INT，Patients.ID却是VARCHAR）？这些细节都会影响优化器的选择。

2. 用EXPLAIN排查执行计划 #

先跑一遍EXPLAIN + 你的查询语句，重点看Patients表那一行的几个关键列：

• type列如果是ALL，那确实是全表扫描没跑了；
• key列如果没显示你建的DoctorID索引，说明这个索引根本没被用上。

常见的索引失效原因： #

• 对索引字段做了函数运算，比如YEAR(p.CreateTime) = 2024，函数会破坏索引的有序性，优化器只能全扫；
• 统计信息过时，MySQL的优化器依赖表的统计信息判断执行成本，你可以跑ANALYZE TABLE Patients;更新统计信息，让优化器重新评估；
• 索引的选择性太差，比如DoctorID字段的重复值特别多（比如大部分患者都归同一个医生），优化器会觉得走索引还不如全扫快。

3. 针对性调整索引策略 #

根据你的查询场景，咱们可以换个思路建索引：

• 如果查询的核心过滤条件是Transactions表的日期（比如要指定日期的交易），给Transactions建(TransDate, PatientID)的复合索引——先快速过滤出指定日期的交易数据，再关联Patients，这样关联的数据量会大幅减少；
• 如果Patients表本身有日期过滤条件，给Patients建(过滤日期字段, DoctorID, ID)的复合索引，把查询需要用到的字段都塞进去，做成覆盖索引，这样MySQL走索引的时候直接就能拿到所有需要的数据，不用再回表查原数据；
• 要是关联的第三张表是Doctors，那可以考虑给Patients建(DoctorID, ID, PatientName)（假设需要患者姓名）的覆盖索引，进一步减少IO开销。

4. 强制干预执行计划（谨慎用） #

如果你确定索引是有效的，但优化器死心眼非要全扫，可以试试强制指定索引：

SELECT d.DoctorName, t.ItemName, t.Amount
FROM Patients p FORCE INDEX (idx_doctorid)
JOIN Transactions t ON p.ID = t.PatientID
JOIN Doctors d ON p.DoctorID = d.ID
WHERE t.TransDate = '2024-05-20';

不过这是最后手段，毕竟MySQL优化器大多数时候是靠谱的，只有当你明确知道索引更优时再用。

另外也可以强制指定关联顺序，比如让MySQL先扫Transactions（因为有日期过滤，数据量更小），再关联Patients：

SELECT d.DoctorName, t.ItemName, t.Amount
FROM Transactions t
STRAIGHT_JOIN Patients p ON p.ID = t.PatientID
STRAIGHT_JOIN Doctors d ON p.DoctorID = d.ID
WHERE t.TransDate = '2024-05-20';

这样能避免优化器选错关联顺序，减少Patients表的扫描范围。

最后再提一句：13000条数据的全扫本身耗时不会特别久，但作为大型查询的一环，积少成多就会出问题。核心还是要让优化器走最适合的索引，把不必要的数据扫描砍掉。

内容的提问来源于stack exchange，提问作者3C41DC