应避免在 where 条件中对字段使用函数，否则导致索引失效和全表扫描；正确做法是将函数移至右侧，保持左侧为裸字段，如用“voucher_date >= ‘2024-06-01’ and voucher_date
WHERE 条件里用函数导致全表扫描
财务系统查账慢，八成卡在
WHERE子句对字段套函数。比如查“本月凭证”，写成WHERE YEAR(voucher_date) = 2024 AND MONTH(voucher_date) = 6，数据库没法走voucher_date索引，只能扫全表。正确做法是把函数移到右边，让左边保持裸字段：
WHERE voucher_date >= '2024-06-01' AND voucher_date < '2024-07-01'
- 日期范围查询必须用开闭区间（左闭右开），避免漏掉
2024-06-30 23:59:59后的记录- 如果字段是
DATETIME或TIMESTAMP，别用BETWEEN，它包含右边界，容易多算一秒- 财务系统常有“凭证日期”和“记账日期”两个字段，确认你查的是哪个——索引建在错的字段上，优化等于白做
JOIN 多张主子表时没控制中间结果集大小
查一张凭证的明细（凭证头 + 凭证行 + 科目 + 部门），四表
JOIN后数据量爆炸，不是因为 SQL 写错，而是没提前过滤。财务查询通常有强筛选条件（如凭证字、期间、科目代码），这些条件要尽早下推到最靠近数据源的表上：
- 把
WHERE voucher_no LIKE 'JZ2024%'放在JOIN前的子查询里，而不是最后统一过滤- 避免
SELECT *，只取真正需要的字段——尤其别带大字段如memo或attachment_id，它们会拖慢网络和内存- 如果子表（如凭证行）数据量远大于头表，考虑先查头表 ID 列表，再用
IN或临时表驱动子表查询，比直接JOIN更稳GROUP BY 后用 HAVING 过滤代替 WHERE
查“余额不为零的科目汇总”，有人写成
HAVING SUM(debit - credit) != 0，看起来对，但执行顺序是：先分组、再聚合、最后HAVING过滤。如果科目总数百万级，分组本身就很重。更优解是把过滤逻辑前移：
- 先在
WHERE里排除明显无发生额的凭证（如status = 'posted'且amount != 0），减少输入行数- 如果业务允许，加一个“本期有发生”的标记字段（如
has_transaction_this_period），用索引快速定位HAVING只用于真正依赖聚合结果的判断，比如“只显示借方发生额超 100 万的部门”，这种无法提前下推ORDER BY 没走索引导致 filesort
财务报表导出常要按凭证号、日期或金额排序，但
ORDER BY voucher_no却触发Using filesort，说明排序字段没被覆盖在索引里。复合索引顺序很关键，特别是涉及多条件查询 + 排序的场景：
- 如果查询是
WHERE period = '202406' AND status = 'posted' ORDER BY voucher_date DESC，索引应建为(period, status, voucher_date)，不是反过来- 避免在
ORDER BY里用表达式，比如ORDER BY ABS(amount)，索引失效- 财务系统常需分页（
LIMIT 20 OFFSET 1000），深分页性能差，建议改用游标分页（WHERE voucher_date）财务数据的“正确性”压倒一切，但慢查询会让人不敢点“导出”按钮。索引不是建得越多越好，而是每一条都要对应到具体查询模式；执行计划里的
type=ALL或Extra里出现Using temporary，基本就是优化起点。
