生产环境SQL需兼顾性能、安全与可维护性；必须带WHERE条件防全表扫描；用EXPLAIN确认执行计划；对高频字段建索引但避免过度；禁用SELECT *；日期范围优先用BETWEEN或>=。

生产环境的SQL使用必须兼顾性能、安全与可维护性，不能只图写得快、查得快。

查询必须带WHERE条件，禁止全表扫描

没有WHERE条件的SELECT会触发全表扫描，在大表上极易拖垮数据库。即使只是临时查数据，也要先用EXPLAIN确认执行计划。

• 对id、状态、时间等高频筛选字段建立合适索引，但避免过度建索引影响写入性能
• 慎用SELECT *，只查真正需要的字段，减少网络传输和内存开销
• 日期范围查询优先用BETWEEN或>= +

DML操作必须走事务，且限制单次影响行数

UPDATE/DELETE不加WHERE是生产事故高发原因；大范围更新不加控制会锁表、阻塞读写、触发主从延迟。

• 所有UPDATE/DELETE必须显式BEGIN + COMMIT/ROLLBACK，禁止自动提交模式下直接执行
• 单条语句影响行数超过1000行，应拆分为分批处理（例如每次500行，配合WHERE id BETWEEN ? AND ?）
• 上线前在测试库用相同数据量压测，观察执行时间、锁等待、慢日志是否新增

禁止在生产库执行DDL变更，除非经过严格评审

ALTER TABLE可能锁表（尤其MySQL 5.6及更早版本）、引发复制中断、导致应用报错，必须规避风险。

• 结构变更统一走DBA审核流程，提供影响评估（锁表时长、预计耗时、回滚方案）
• 大表加索引或字段，使用在线DDL工具（如pt-online-schema-change、gh-ost）
• 禁止在业务高峰时段执行DDL；变更窗口需预留足够回退时间

应用层SQL要参数化，杜绝拼接字符串

字符串拼接SQL不仅有SQL注入风险，还会导致大量相似SQL无法复用执行计划，增加parse压力。

• 所有变量必须通过预编译参数（? 或 :name）传入，后端框架如MyBatis默认支持
• 避免在SQL里用CONCAT拼接条件，改用动态SQL标签（如MyBatis的）或应用层逻辑组装WHERE
• 禁止将用户输入（如搜索关键词、ID列表）直接拼进IN子句，改用批量参数或临时表