Excel VBA+Mysql系统开发中sql编写的9大原则14大细则【建议收藏】

一、基本准则

1. 简明性：SQL语句应力求简洁，避免冗余和复杂结构。

2. 规范性：应遵循SQL标准语法与函数，提升代码在不同数据库间的兼容性。

3. 性能优先：合理使用索引，防止全表扫描，降低系统资源占用。

4. 易于维护：代码应便于后续修改与扩展，避免硬编码，多采用配置参数和变量。

二、核心规范

1. 命名规则a. 表名和字段名应具备明确含义，便于识别。b. 所有数据库对象名称（如表、列、索引）采用小写字母，以下划线分隔单词。c. 视图、存储过程、函数等对象的命名应体现其业务用途。d. 采用统一的命名风格，例如通过前缀或后缀标识对象类型。

2. 注释要求a. 对复杂逻辑的查询、存储过程和触发器，应添加注释说明其功能、输入输出及业务逻辑。b. 注释内容应与代码同步更新，保证一致性。

3. 关键字写法：SQL中的保留字和关键字应采用大写形式，以便与其他标识符区分。

4. 格式排版a. 采用缩进提升可读性，每级缩进建议使用两个空格或一个制表位。b. 每条SQL语句宜独立成行，或合理换行排列，便于阅读。c. 不同逻辑段之间可用空行分隔，增强结构清晰度。

5. 数据类型选用a. 根据字段特性选择适当的数据类型，避免存储空间浪费。b. 字符串字段应根据内容长度选用VARCHAR或TEXT。c. 日期时间数据应使用专用的日期时间类型。

6. 索引策略a. 应为频繁出现在查询条件中的字段建立索引。b. 避免索引过多，以免影响插入、更新和删除的效率。

7. 查询调优a. 禁止使用SELECT *，应明确列出所需字段。b. WHERE条件应具备筛选性，减少无效数据扫描。c. 多表关联时，优先使用JOIN替代子查询以提升性能。

8. 事务管理a. 确保事务具备原子性、一致性、隔离性和持久性。b. 防止事务运行时间过长，降低锁冲突和死锁风险。

9. 安全防护a. 采用参数化查询或预处理语句，防范SQL注入攻击。b. 对数据库权限进行精细化控制，保证用户仅访问授权数据。

四、性能优化细则

1. 禁止使用SELECT *在实际开发中，不建议采用SELECT * 查询所有字段，而是只选取必要字段，原因包括：

• 性能影响：返回全部列会增大数据传输量，延长处理时间；仅查询所需列可显著提升响应速度。

• 安全隐患：可能无意中泄露敏感字段（如日志、报错信息中）。

• 结构变动适应性差：表结构变更（增删列）时，SELECT * 可能导致结果异常或应用出错。

• 维护困难：代码依赖隐含字段，降低可读性和可控性。

1. 尽量避免OR条件在查询中滥用OR可能引发性能问题，尤其在数据量大的表中，易导致索引失效和全表扫描。主要弊端包括：

• 索引无法充分利用，优化器可能选择全表扫描。

• 查询效率大幅下降，尤其在多条件组合时。改进建议：

• 使用UNION合并多个查询，替代OR。

• 建立复合索引，覆盖OR中涉及的多个列。

• 重构查询逻辑，通过其他方式实现等价功能。

• 借助EXPLAIN分析执行计划，针对性优化。

1. 数字型优于字符串型主键ID应使用INT或BIGINT，性别、状态等字段适合用TINYINT。数字类型的优势：

• 存储空间更小，结构紧凑。

• 计算效率更高，数字运算快于字符串处理。

• 排序和比较更便捷。

1. 优先VARCHAR而非CHARCHAR为定长类型，无论实际数据多长都占用固定空间，适合长度固定的数据（如星期）。VARCHAR为变长类型，根据实际长度分配空间，适合长度不确定的字段（如用户名、地址）。使用VARCHAR可节省存储，避免空间浪费。

2. 避免使用!=和<>!=和<>通常难以利用索引，尤其在排除少量值时仍可能扫描大量数据。建议使用标准ANSI SQL操作符（如=、<、>等），既保证性能，也提升跨数据库迁移的兼容性。

3. 内连接优先于外连接INNER JOIN仅返回匹配记录，数据量较小，性能更优；LEFT/RIGHT JOIN会返回一侧全部记录，开销更大。建议优先使用内连接，并将筛选条件尽量放在左侧小表上，遵循“小表驱动大表”原则。

4. GROUP BY的合理使用

• 选择合适的分组字段，优先使用WHERE中已过滤的列。

• 配合聚合函数（如COUNT、SUM）完成统计。

• 结合ORDER BY排序输出。

• 避免隐式类型转换，确保字段类型一致。

• 使用EXPLAIN分析执行计划，优先使用索引列分组。

• 注意NULL值处理，可结合IFNULL使用。

• 复杂分组可拆分为子查询或临时表，提升可读性和效率。

1. 表连接与索引数量控制

• 多表关联不宜超过5个，否则编译开销大，临时表增多，可读性差。

• 若关联表过多，可能反映设计不合理，建议拆分。

• 阿里规范建议联表不超过3张。

• 索引数量也应控制在5个以内，过多会影响写入性能，占用空间，增加排序开销。

• 索引创建原则：

• 主键自动为索引。

• 优先选择占用空间小、长度固定的字段（如整数、CHAR）。

• 常用于WHERE、GROUP BY、ORDER BY、关联条件的字段应建索引。

• 频繁更新的字段不宜建索引。

• 大文本字段不适合建索引。

1. 联合索引最左匹配原则联合索引（A, B, C）中，只有查询条件包含最左列A时，索引才有效。若仅涉及B或C，索引失效。因此，设计时应将最常用的筛选列放在最左侧，若不满足条件，可考虑单列索引或重新设计。

10.LIKE查询优化建议

• 避免将%放在开头，否则索引失效，应尽量置于末尾。

• 减少通配符使用频率，防止全表扫描。

• 对复杂文本搜索，可启用全文索引（FULLTEXT）。

• 匹配字符集与校对规则，保证查询准确。

• 若同时包含WHERE和ORDER BY，可构建覆盖索引。

• 禁止在索引列上使用函数或表达式。

• 确保数据类型一致，避免隐式转换。

11.执行计划分析（EXPLAIN）

• system：仅一行数据，极少出现。

• const：主键查询，最多一行匹配。

• eq_ref：最佳连接类型之一，每组合读取一行。

• ref：匹配索引值的多行读取。

• range：索引范围扫描，如=、<>、BETWEEN、IN等。

• index：索引树扫描，优于ALL。

• all：全表扫描，最差。优化目标至少达到ref或range级别。Extra字段常见值：

• Using index：仅从索引获取数据，无需回表。

• Using where：需回表查询，若与ALL或index组合可能有问题。

• Using temporary：需创建临时表，常见于GROUP BY和ORDER BY组合。

12.热数据表水平拆分与冗余以订单表为例，可按周或按月拆分，并保留多级冗余（如天表和周表），当日查询走天表，历史查询走周表，天表可定期清理。

13.DELETE操作限制

• 添加时间条件和LIMIT，防止误删大量数据，便于通过binlog恢复。

• 带时间条件的删除可利用索引提升效率。

• 避免长事务，防止行锁和间隙锁影响业务。

• 大批量删除易导致锁表或超时，建议分批执行。

14.批量插入优化推荐使用多值插入格式：INSERT INTO table (field1) VALUES ('value1'), ('value2'), ('value3')；相比逐条插入，效率可提升数万倍，数据量越大效果越显著。

反例：

应改为：

VBA系统定制请站内联系，更多系统信息请阅读原文