MariaDB 开发规范

数据库开发规范是确保数据库系统高性能、高可用、易维护的重要保障。一个好的开发规范能够帮助开发人员和 DBA 协同工作，减少数据库问题，提高系统整体质量。

命名规范

1. 基本原则

可读性优先：命名应清晰、简洁，能够准确反映对象的用途
一致性：同一类型的对象应使用相同的命名规则
避免关键字：不使用 MariaDB 关键字作为对象名
区分大小写：建议使用小写字母，单词之间用下划线分隔（snake_case）
长度限制：对象名长度不宜过长，建议不超过 64 个字符

2. 数据库命名

采用业务名称或项目名称命名
建议使用小写字母，单词之间用下划线分隔
示例：ecommerce_db、user_center_db

3. 表命名

采用 业务模块_表名 的格式
建议使用名词复数形式
示例：user_profile、order_items、product_categories

4. 字段命名

采用清晰的英文单词或缩写
避免使用不明确的缩写
示例：user_id、create_time、is_deleted

5. 索引命名

主键索引：默认命名为 PRIMARY，无需手动指定
唯一索引：uk_表名_字段名1_字段名2
普通索引：idx_表名_字段名1_字段名2
全文索引：ft_表名_字段名
示例：uk_user_email、idx_order_create_time

6. 存储过程与函数命名

存储过程：sp_模块名_功能名
函数：fn_模块名_功能名
示例：sp_order_generate_no、fn_calculate_discount

7. 触发器命名

trg_表名_触发时机_触发事件
触发时机：before、after
触发事件：insert、update、delete
示例：trg_user_after_insert、trg_order_before_update

8. 视图命名

v_视图名 或 view_视图名
示例：v_user_order_stats、view_product_inventory

9. 临时表命名

temp_表名 或 tmp_表名
示例：temp_order_export、tmp_user_import

数据类型选择

1. 基本原则

最小化原则：选择最小的、合适的数据类型
精确性原则：数值类型选择精确的数据类型
一致性原则：相同含义的字段使用相同的数据类型
版本兼容性：考虑不同 MariaDB 版本的数据类型支持

2. 数值类型

数据类型	适用场景	版本差异
`TINYINT`	小整数（-128 ~ 127），如状态字段	所有版本支持
`SMALLINT`	中等整数（-32768 ~ 32767），如数量字段	所有版本支持
`INT`	常用整数类型（-2147483648 ~ 2147483647）	所有版本支持
`BIGINT`	大整数（-9223372036854775808 ~ 9223372036854775807），如 ID 字段	所有版本支持
`DECIMAL`	精确小数，如金额、价格	所有版本支持，建议指定精度和小数位数，如 `DECIMAL(10,2)`
`FLOAT`	单精度浮点数，不建议用于精确计算	所有版本支持，尽量避免使用
`DOUBLE`	双精度浮点数，不建议用于精确计算	所有版本支持，尽量避免使用

3. 字符串类型

数据类型	适用场景	版本差异
`CHAR`	固定长度字符串，如身份证号、手机号	所有版本支持，建议长度不超过 255
`VARCHAR`	可变长度字符串，如用户名、邮箱	所有版本支持，MariaDB 10.2+ 支持最大长度 65535
`TEXT`	大文本数据，如文章内容、评论	所有版本支持，建议仅用于超过 255 字符的场景
`BLOB`	二进制数据，如图片、文件	所有版本支持，建议尽量避免存储大文件，考虑使用对象存储
`ENUM`	枚举类型，如状态字段（有限值）	所有版本支持，建议枚举值不超过 20 个
`SET`	集合类型，如标签字段（多选）	所有版本支持，建议谨慎使用，维护成本高

4. 日期时间类型

数据类型	适用场景	版本差异
`DATE`	日期（YYYY-MM-DD），如出生日期	所有版本支持
`TIME`	时间（HH:MM:SS），如开始时间	所有版本支持
`DATETIME`	日期时间（YYYY-MM-DD HH:MM:SS），如创建时间	所有版本支持，MariaDB 10.1+ 支持 `DATETIME(6)`（微秒精度）
`TIMESTAMP`	时间戳（从 1970-01-01 开始的秒数），如更新时间	所有版本支持，自动更新时区，建议用于需要时区转换的场景
`YEAR`	年份（YYYY），如毕业年份	所有版本支持，建议使用 `DATE` 类型替代，便于扩展

5. 特殊类型

数据类型	适用场景	版本差异
`JSON`	JSON 数据，如配置信息、复杂结构	MariaDB 10.2+ 支持原生 JSON 类型
`UUID`	全局唯一标识符	MariaDB 10.7+ 支持原生 UUID 类型，之前版本可使用 `UUID()` 函数生成
`INET6`	IP 地址（IPv4 和 IPv6）	MariaDB 10.0+ 支持 `INET6_ATON()` 和 `INET6_NTOA()` 函数

表结构设计

1. 范式设计

优先遵循第三范式（3NF）：表中的每一列都直接依赖于主键，不存在传递依赖
适当反范式：在性能要求高的场景下，可以适当冗余字段，减少 JOIN 操作
示例：订单表中冗余商品名称，避免查询时 JOIN 商品表

2. 主键设计

优先使用自增 ID：INT UNSIGNED AUTO_INCREMENT 或 BIGINT UNSIGNED AUTO_INCREMENT
避免使用复合主键：复合主键会增加索引大小和维护成本
特殊场景使用 UUID：如分布式系统、需要全局唯一 ID 的场景
版本差异：MariaDB 10.3+ 支持 AUTO_INCREMENT = N 语法，用于设置自增起始值

3. 字段设计

非空约束：尽量设置 NOT NULL 约束，避免 NULL 值带来的问题
默认值：为非空字段设置合理的默认值
示例：create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
版本差异：MariaDB 10.1+ 支持 DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

4. 分区表设计

适用场景：
- 大表（数据量超过 1000 万行）
- 按时间或范围查询频繁
- 需要快速归档或删除历史数据
分区类型：
- RANGE：按范围分区（如时间范围）
- LIST：按列表分区（如地区代码）
- HASH：按哈希值分区
- KEY：按键值分区
示例：

sql

-- 按时间范围分区
CREATE TABLE orders (
    order_id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
    order_no VARCHAR(32) NOT NULL,
    create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB
PARTITION BY RANGE (YEAR(create_time)) (
    PARTITION p2023 VALUES LESS THAN (2024),
    PARTITION p2024 VALUES LESS THAN (2025),
    PARTITION p2025 VALUES LESS THAN (2026)
);

版本差异：MariaDB 10.0+ 支持更多分区类型和功能

5. 临时表设计

全局临时表：CREATE GLOBAL TEMPORARY TABLE，会话间共享结构
会话临时表：CREATE TEMPORARY TABLE，会话结束后自动删除
建议：使用会话临时表，避免全局临时表的并发问题

6. 表注释

为表和字段添加注释：便于后续维护和理解
示例：

sql

CREATE TABLE user_profile (
    user_id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY COMMENT '用户ID',
    username VARCHAR(64) NOT NULL COMMENT '用户名',
    email VARCHAR(128) NOT NULL COMMENT '邮箱',
    create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间'
) COMMENT='用户信息表';

索引设计

1. 索引类型

索引类型	适用场景	版本差异
B-Tree 索引	大多数查询场景，如等值查询、范围查询	所有版本支持
哈希索引	等值查询，不支持范围查询	仅 MEMORY 存储引擎支持
全文索引	文本搜索，如文章内容、评论	MariaDB 10.0+ 支持 InnoDB 全文索引
空间索引	地理空间数据查询	MariaDB 10.0+ 支持 InnoDB 空间索引
前缀索引	长字符串字段，如 URL、邮箱	所有版本支持
覆盖索引	查询只需要从索引中获取数据，无需回表	所有版本支持

2. 索引创建原则

选择性原则：选择区分度高的字段作为索引
最左前缀原则：复合索引的查询条件应包含最左前缀
避免过度索引：每个索引都会增加写操作成本
覆盖查询：尽量让查询使用覆盖索引，减少回表操作
主键即索引：InnoDB 表的主键会自动创建聚簇索引

3. 索引使用注意事项

避免在索引字段上使用函数：如 DATE(create_time) = '2023-01-01'
避免隐式类型转换：如字符串字段与数值比较
避免使用 NOT IN、!= 等操作符：这些操作符会导致全表扫描
避免 SELECT *：只查询需要的字段，减少 IO 操作

4. 复合索引设计

顺序原则：将选择性高的字段放在前面
最左前缀匹配：查询条件应包含复合索引的最左前缀
示例：
- 表：order_items（order_id, product_id, quantity, price）
- 查询：SELECT * FROM order_items WHERE order_id = 1 AND product_id = 2
- 复合索引：idx_order_product (order_id, product_id)

5. 索引维护

定期分析索引使用情况：使用 SHOW INDEX 和 sys.schema_index_statistics
删除无用索引：使用 DROP INDEX 删除不使用的索引
重建索引：对于频繁更新的表，定期重建索引以提高性能
示例：

sql

-- 查看索引使用情况
SELECT * FROM sys.schema_index_statistics WHERE table_schema = 'ecommerce_db';

-- 重建索引
ALTER TABLE order_items ENGINE=InnoDB;  -- 重建所有索引
-- 或
ALTER TABLE order_items REBUILD INDEX idx_order_product;  -- 重建指定索引

SQL 编写规范

1. SELECT 语句

明确指定字段：避免使用 SELECT *
使用 LIMIT：查询大量数据时，使用 LIMIT 限制返回行数
避免子查询：复杂子查询可以转换为 JOIN 操作
使用 WITH 子句：复杂查询使用 CTE（Common Table Expressions）提高可读性
版本差异：MariaDB 10.2+ 支持 CTE
示例：

sql

-- 不推荐
SELECT * FROM users WHERE age > 18;

-- 推荐
SELECT user_id, username, email FROM users WHERE age > 18 LIMIT 100;

-- 使用 CTE
WITH recent_orders AS (
    SELECT order_id, user_id FROM orders WHERE create_time >= '2023-01-01'
)
SELECT u.username, ro.order_id 
FROM users u 
JOIN recent_orders ro ON u.user_id = ro.user_id;

2. INSERT 语句

指定字段名：明确指定插入的字段名，避免依赖表结构
批量插入：使用 INSERT INTO ... VALUES (...), (...), (...) 批量插入
避免循环插入：应用程序中避免使用循环插入，应使用批量插入
示例：

sql

-- 不推荐
INSERT INTO users VALUES (NULL, 'username', 'email@example.com');

-- 推荐
INSERT INTO users (username, email) VALUES ('username', 'email@example.com');

-- 批量插入
INSERT INTO users (username, email) VALUES 
('user1', 'user1@example.com'),
('user2', 'user2@example.com'),
('user3', 'user3@example.com');

3. UPDATE 语句

使用 WHERE 子句：避免无 WHERE 条件的 UPDATE
使用 LIMIT：批量更新时，使用 LIMIT 限制更新行数
避免更新主键：主键更新会导致索引重建
示例：

sql

-- 不推荐
UPDATE users SET status = 1;

-- 推荐
UPDATE users SET status = 1 WHERE create_time < '2023-01-01' LIMIT 1000;

4. DELETE 语句

使用 WHERE 子句：避免无 WHERE 条件的 DELETE
使用 LIMIT：批量删除时，使用 LIMIT 限制删除行数
优先使用软删除：添加 is_deleted 字段，标记删除状态
示例：

sql

-- 不推荐
DELETE FROM users;

-- 推荐：软删除
UPDATE users SET is_deleted = 1 WHERE create_time < '2023-01-01' LIMIT 1000;

-- 物理删除（谨慎使用）
DELETE FROM users WHERE is_deleted = 1 AND delete_time < '2023-01-01' LIMIT 1000;

5. JOIN 语句

使用明确的 JOIN 类型：避免隐式 JOIN（逗号分隔的表名）
限制 JOIN 表数量：JOIN 表数量不宜过多，建议不超过 5 个
使用 ON 子句指定连接条件：避免在 WHERE 子句中指定连接条件
示例：

sql

-- 不推荐（隐式 JOIN）
SELECT u.username, o.order_no 
FROM users u, orders o 
WHERE u.user_id = o.user_id;

-- 推荐（显式 JOIN）
SELECT u.username, o.order_no 
FROM users u 
INNER JOIN orders o ON u.user_id = o.user_id;

6. 子查询

避免嵌套过深：子查询嵌套不宜超过 3 层
考虑使用 JOIN 替代：复杂子查询可以转换为 JOIN 操作
使用 EXISTS 替代 IN：对于大表，EXISTS 性能优于 IN
示例：

sql

-- 不推荐（IN 子查询）
SELECT username FROM users WHERE user_id IN (SELECT user_id FROM orders WHERE amount > 1000);

-- 推荐（EXISTS 子查询）
SELECT username FROM users u WHERE EXISTS (
    SELECT 1 FROM orders o WHERE o.user_id = u.user_id AND o.amount > 1000
);

-- 推荐（JOIN）
SELECT u.username FROM users u JOIN orders o ON u.user_id = o.user_id WHERE o.amount > 1000;

事务与锁规范

1. 事务隔离级别

默认使用 READ COMMITTED：大多数场景下性能和一致性的平衡
根据业务需求选择：
- READ UNCOMMITTED：性能最高，一致性最低
- READ COMMITTED：平衡性能和一致性
- REPEATABLE READ：高一致性，可能导致幻读
- SERIALIZABLE：最高一致性，性能最低
版本差异：MariaDB 10.3+ 支持 READ COMMITTED 隔离级别下的 MVCC 优化

2. 事务使用规范

保持事务短小：事务执行时间不宜过长，避免长时间持有锁
避免在事务中执行非数据库操作：如调用外部 API、文件操作等
显式提交或回滚：避免依赖自动提交
使用 SAVEPOINT：复杂事务可以使用 SAVEPOINT 进行部分回滚
示例：

sql

START TRANSACTION;

-- 执行SQL操作
INSERT INTO orders (order_no, user_id, amount) VALUES ('202301010001', 1, 100);
INSERT INTO order_items (order_id, product_id, quantity, price) VALUES (LAST_INSERT_ID(), 1, 2, 50);

-- 提交事务
COMMIT;
-- 或回滚
-- ROLLBACK;

3. 锁机制

避免行锁升级为表锁：确保查询使用索引，避免全表扫描
减少锁冲突：
- 读写分离
- 合理设计表结构
- 优化查询语句
使用乐观锁：在高并发场景下，使用版本号或时间戳实现乐观锁
示例：

sql

-- 乐观锁示例
UPDATE products 
SET stock = stock - 1, version = version + 1 
WHERE product_id = 1 AND version = 1;

4. 死锁预防

统一操作顺序：不同事务操作表的顺序保持一致
减少事务持有时间：尽快提交或回滚事务
使用索引：确保查询使用索引，避免全表扫描
设置合理的锁超时时间：innodb_lock_wait_timeout

存储过程与函数规范

1. 编写规范

使用 DELIMITER 改变分隔符：避免存储过程中的分号与语句分隔符冲突
添加参数注释：明确参数的含义和类型
使用异常处理：使用 DECLARE CONTINUE HANDLER 处理异常
避免使用动态 SQL：动态 SQL 会增加安全风险和维护成本
示例：

sql

DELIMITER //

CREATE PROCEDURE sp_generate_order_no(
    OUT p_order_no VARCHAR(32)
) COMMENT '生成订单号'
BEGIN
    DECLARE v_timestamp VARCHAR(14);
    DECLARE v_random INT;
    
    -- 生成时间戳
    SELECT DATE_FORMAT(NOW(), '%Y%m%d%H%i%s') INTO v_timestamp;
    
    -- 生成随机数
    SELECT FLOOR(RAND() * 1000) INTO v_random;
    
    -- 组合订单号
    SET p_order_no = CONCAT(v_timestamp, LPAD(v_random, 3, '0'));
END //

DELIMITER ;

2. 性能优化

避免在存储过程中使用大量循环：循环操作性能较差
使用集合操作替代循环：如 INSERT INTO ... SELECT
避免返回大量数据：存储过程返回数据量不宜过大
定期优化存储过程：分析执行计划，优化查询语句

3. 安全性

使用参数化查询：避免 SQL 注入
限制存储过程权限：仅授予必要的权限
避免在存储过程中使用动态 SQL：如必须使用，确保参数经过严格验证

触发器与事件规范

1. 触发器

使用场景：
- 数据审计：记录数据变更历史
- 数据一致性维护：如级联更新
- 业务规则验证：如数据完整性检查
注意事项：
- 触发器执行时间不宜过长
- 避免在触发器中调用存储过程或函数
- 避免循环触发
- 版本差异：MariaDB 10.0+ 支持 FOR EACH ROW 触发器
示例：

sql

-- 创建审计触发器
CREATE TRIGGER trg_user_after_update
AFTER UPDATE ON users
FOR EACH ROW
BEGIN
    INSERT INTO user_audit (
        user_id, username, email, operation_type, operation_time, operator
    ) VALUES (
        OLD.user_id, OLD.username, OLD.email, 'UPDATE', NOW(), USER()
    );
END;

2. 事件

使用场景：
- 定期数据清理：如删除过期数据
- 定期统计：如生成日报、周报
- 定期备份：如备份表数据
注意事项：
- 事件执行时间不宜过长
- 避免在事件中执行大量数据操作
- 设置合理的执行频率
- 版本差异：MariaDB 10.0+ 支持事件调度器
示例：

sql

-- 启用事件调度器
SET GLOBAL event_scheduler = ON;

-- 创建定期清理事件
CREATE EVENT event_clean_expired_orders
ON SCHEDULE EVERY 1 DAY
STARTS '2023-01-01 00:00:00'
DO
BEGIN
    DELETE FROM orders WHERE create_time < DATE_SUB(NOW(), INTERVAL 3 MONTH) LIMIT 1000;
END;

性能优化规范

1. 查询优化

分析执行计划：使用 EXPLAIN 或 EXPLAIN ANALYZE 分析查询计划
使用索引：确保查询使用合适的索引
优化 JOIN 操作：减少 JOIN 表数量，使用合适的 JOIN 类型
避免全表扫描：确保查询条件包含索引字段
示例：

sql

-- 分析执行计划
EXPLAIN SELECT * FROM users WHERE username = 'test';

-- 分析并执行查询（MariaDB 10.1+）
EXPLAIN ANALYZE SELECT * FROM users WHERE username = 'test';

2. 慢查询处理

启用慢查询日志：设置 slow_query_log = ON 和 long_query_time
分析慢查询日志：使用 mysqldumpslow 或 pt-query-digest 分析慢查询
优化慢查询：根据执行计划优化查询语句或索引
版本差异：MariaDB 10.1+ 支持 performance_schema，可以更详细地分析慢查询

3. 执行计划分析

关注 type 列：
- const：最佳，使用主键或唯一索引
- eq_ref：良好，使用唯一索引
- ref：较好，使用非唯一索引
- range：一般，范围查询
- index：较差，全索引扫描
- ALL：最差，全表扫描
关注 key 列：显示查询使用的索引
关注 rows 列：估计扫描的行数，值越小越好
关注 Extra 列：
- Using index：使用覆盖索引，良好
- Using where：使用 WHERE 条件过滤
- Using temporary：使用临时表，较差
- Using filesort：使用文件排序，较差

安全性规范

1. 防止 SQL 注入

使用参数化查询：避免直接拼接 SQL 语句
输入验证：对用户输入进行严格验证
使用存储过程：存储过程可以防止 SQL 注入
最小权限原则：仅授予必要的权限

2. 权限管理

遵循最小权限原则：仅授予用户必要的权限
定期审计权限：定期检查用户权限，及时回收不必要的权限
使用角色管理权限：MariaDB 10.0+ 支持角色管理
示例：

sql

-- 创建角色
CREATE ROLE 'readonly';

-- 授予权限
GRANT SELECT ON ecommerce_db.* TO 'readonly';

-- 分配角色给用户
GRANT 'readonly' TO 'app_user'@'localhost';

3. 数据加密

传输加密：使用 SSL/TLS 加密数据库连接
存储加密：
- 表级加密：ENCRYPTED=YES（MariaDB 10.1+）
- 列级加密：使用 AES_ENCRYPT() 和 AES_DECRYPT() 函数
版本差异：MariaDB 10.1+ 支持表级加密，MariaDB 10.3+ 支持透明数据加密（TDE）

4. 审计与日志

启用审计日志：记录数据库操作，便于追踪和审计
定期备份日志：避免日志丢失
限制日志访问权限：仅授予必要的权限访问日志

开发流程规范

1. 开发阶段

编写 SQL 语句：按照规范编写 SQL 语句
测试 SQL 语句：在测试环境中测试 SQL 语句的性能和正确性
提交代码审查：提交 SQL 语句进行代码审查
记录变更：记录 SQL 语句的变更历史

2. 测试阶段

单元测试：测试单个 SQL 语句或存储过程
集成测试：测试多个模块的集成
性能测试：测试 SQL 语句的性能
安全测试：测试 SQL 注入、权限管理等

3. 上线阶段

制定上线计划：包括上线时间、影响范围、回滚方案
执行上线：在业务低峰期执行上线
监控上线过程：监控数据库性能和业务指标
验证上线结果：验证业务功能和性能

4. 回滚机制

制定回滚方案：针对可能出现的问题，制定详细的回滚方案
测试回滚方案：在测试环境中测试回滚方案
准备回滚脚本：编写回滚脚本，便于快速回滚

常见问题 (FAQ)

Q: 如何选择合适的数据类型？

A: 选择数据类型时应考虑：

数据范围：选择能够容纳数据的最小类型
精度要求：数值类型使用 DECIMAL 存储精确数值
查询性能：频繁查询的字段使用高效的数据类型
版本兼容性：考虑不同 MariaDB 版本的数据类型支持
示例：存储金额应使用 DECIMAL(10,2)，存储时间应使用 DATETIME 或 TIMESTAMP

Q: 复合索引的字段顺序如何确定？

A: 复合索引的字段顺序应考虑：

选择性原则：将区分度高的字段放在前面
最左前缀原则：查询条件应包含复合索引的最左前缀
查询频率：将频繁用于查询的字段放在前面
示例：如果查询条件经常是 WHERE order_id = ? AND product_id = ?，则复合索引应为 (order_id, product_id)

Q: 如何优化慢查询？

A: 优化慢查询的步骤：

分析执行计划：使用 EXPLAIN 查看查询计划
检查索引使用情况：确保查询使用了合适的索引
优化查询语句：
- 避免 SELECT *
- 避免全表扫描
- 优化 JOIN 操作
- 减少子查询嵌套
调整参数：如 innodb_buffer_pool_size、query_cache_size
考虑表结构优化：如分库分表、垂直拆分

Q: 如何预防死锁？

A: 预防死锁的方法：

统一操作顺序：不同事务操作表的顺序保持一致
减少事务持有时间：尽快提交或回滚事务
使用索引：确保查询使用索引，避免全表扫描
设置合理的锁超时时间：innodb_lock_wait_timeout
使用乐观锁：在高并发场景下，使用版本号或时间戳实现乐观锁

Q: 存储过程和函数有什么区别？

A: 存储过程和函数的主要区别：

特性	存储过程	函数
返回值	可以返回多个值，通过 OUT/INOUT 参数	只能返回一个值
调用方式	使用 `CALL` 语句调用	可以在 SQL 语句中使用，如 `SELECT fn_calculate_discount(amount)`
事务支持	支持事务	不支持事务
用途	复杂业务逻辑、批量操作	计算、转换等简单操作

Q: 如何选择事务隔离级别？

A: 事务隔离级别的选择应根据业务需求：

READ UNCOMMITTED：适用于对一致性要求低、性能要求高的场景
READ COMMITTED：适用于大多数场景，平衡性能和一致性
REPEATABLE READ：适用于对一致性要求高、不允许幻读的场景
SERIALIZABLE：适用于对一致性要求极高、并发低的场景

Q: 如何分析索引使用情况？

A: 分析索引使用情况的方法：

使用 SHOW INDEX：查看表的索引信息
使用 sys.schema_index_statistics：查看索引的使用统计信息
使用 performance_schema：详细分析索引的使用情况（MariaDB 10.1+）

示例：

sql

SELECT * FROM sys.schema_index_statistics WHERE table_schema = 'ecommerce_db';

Q: 如何处理大表？

A: 处理大表的方法：

分区表：按时间或范围分区，便于管理和查询
分库分表：将大表拆分为多个小表，分散存储压力
垂直拆分：将表按业务功能拆分，减少表的复杂度
归档历史数据：将不常用的历史数据归档到其他表或存储介质
优化查询：使用索引、覆盖查询等优化查询性能

总结

MariaDB 开发规范是确保数据库系统高性能、高可用、易维护的重要保障。本规范从命名规范、数据类型选择、表结构设计、索引设计、SQL 编写、事务管理、存储过程与函数、触发器与事件、性能优化、安全性和开发流程等方面，为开发人员和 DBA 提供了全面的指导。

遵循开发规范能够：

提高数据库性能和可靠性
减少数据库问题和故障
提高开发效率和协作能力
降低维护成本和风险
确保数据安全和合规性

开发规范不是一成不变的，需要根据业务发展和技术进步不断更新和完善。建议定期 review 和更新开发规范，确保其始终适应业务需求和技术趋势。

MariaDB 开发规范 ​

命名规范 ​

1. 基本原则 ​

2. 数据库命名 ​

3. 表命名 ​

4. 字段命名 ​

5. 索引命名 ​

6. 存储过程与函数命名 ​

7. 触发器命名 ​

8. 视图命名 ​

9. 临时表命名 ​

数据类型选择 ​

1. 基本原则 ​

2. 数值类型 ​

3. 字符串类型 ​

4. 日期时间类型 ​

5. 特殊类型 ​

表结构设计 ​

1. 范式设计 ​

2. 主键设计 ​

3. 字段设计 ​

4. 分区表设计 ​

5. 临时表设计 ​

6. 表注释 ​

索引设计 ​

1. 索引类型 ​

2. 索引创建原则 ​

3. 索引使用注意事项 ​

4. 复合索引设计 ​

5. 索引维护 ​

SQL 编写规范 ​

1. SELECT 语句 ​

2. INSERT 语句 ​

3. UPDATE 语句 ​

4. DELETE 语句 ​

5. JOIN 语句 ​

6. 子查询 ​

事务与锁规范 ​

1. 事务隔离级别 ​

2. 事务使用规范 ​

3. 锁机制 ​

4. 死锁预防 ​

存储过程与函数规范 ​

1. 编写规范 ​

2. 性能优化 ​

3. 安全性 ​

触发器与事件规范 ​

1. 触发器 ​

2. 事件 ​

性能优化规范 ​

1. 查询优化 ​

2. 慢查询处理 ​

3. 执行计划分析 ​

安全性规范 ​

1. 防止 SQL 注入 ​

2. 权限管理 ​

3. 数据加密 ​

4. 审计与日志 ​

开发流程规范 ​

1. 开发阶段 ​

2. 测试阶段 ​

3. 上线阶段 ​

4. 回滚机制 ​

常见问题 (FAQ) ​

Q: 如何选择合适的数据类型？ ​

Q: 复合索引的字段顺序如何确定？ ​

Q: 如何优化慢查询？ ​

Q: 如何预防死锁？ ​

Q: 存储过程和函数有什么区别？ ​

Q: 如何选择事务隔离级别？ ​

Q: 如何分析索引使用情况？ ​

Q: 如何处理大表？ ​

总结 ​

MariaDB 开发规范

命名规范

1. 基本原则

2. 数据库命名

3. 表命名

4. 字段命名

5. 索引命名

6. 存储过程与函数命名

7. 触发器命名

8. 视图命名

9. 临时表命名

数据类型选择

1. 基本原则

2. 数值类型

3. 字符串类型

4. 日期时间类型

5. 特殊类型

表结构设计

1. 范式设计

2. 主键设计

3. 字段设计

4. 分区表设计

5. 临时表设计

6. 表注释

索引设计

1. 索引类型

2. 索引创建原则

3. 索引使用注意事项

4. 复合索引设计

5. 索引维护

SQL 编写规范

1. SELECT 语句

2. INSERT 语句

3. UPDATE 语句

4. DELETE 语句

5. JOIN 语句

6. 子查询

事务与锁规范

1. 事务隔离级别

2. 事务使用规范

3. 锁机制

4. 死锁预防

存储过程与函数规范

1. 编写规范

2. 性能优化

3. 安全性

触发器与事件规范

1. 触发器

2. 事件

性能优化规范

1. 查询优化

2. 慢查询处理

3. 执行计划分析

安全性规范

1. 防止 SQL 注入

2. 权限管理

3. 数据加密

4. 审计与日志

开发流程规范

1. 开发阶段

2. 测试阶段

3. 上线阶段

4. 回滚机制

常见问题 (FAQ)

Q: 如何选择合适的数据类型？

Q: 复合索引的字段顺序如何确定？

Q: 如何优化慢查询？

Q: 如何预防死锁？

Q: 存储过程和函数有什么区别？

Q: 如何选择事务隔离级别？

Q: 如何分析索引使用情况？

Q: 如何处理大表？

总结