tidb 开发规范

作者： tplinux 原文来源：https://tidb.net/blog/a4cf20ab

tidb 开发规范

如果有不对的地方求留言指正

一 减少大事务

3.0 的版本

1.1 每个事务内的 SQL 数量不超过 5000 条。

1.2 每个键值对不超过 6MB。

1.3 键值对的总大小不超过 100MB

1.4 键值对的总数不超过 300,000(总的行数 *(1 + 索引个数) < 30 万)

4.0 版本 对大事务支持进一步优化

1.5 单个事务最大支持 10GB

1.6 取消键值对的总数不超过 300,000 这个限制

虽然 4.0 对大事务进行优化和改善，但 DBA 建议对大事务进行拆分小事务，减少数据库压力，提示数据库性能。

二 禁止使用 (不支持功能)

2.1 存储过程和函数、 触发器、 事件、 自定义函数、外键、全文索引

2.2 字符集 非 ascii/latin1/binary/utf8/utf8mb4 的字符集

三 库表设计与 SQL

3.1. 建议取消主键 使用唯一健 +not null，理由方便手动分区，从而处理热点写问题。如果必须使用自增主键建议 bigint+AUTO_RANDOM

3.2. 如果有 AP 类型业务，建议申请服务器使用 TiFlash，从而提升读的性能

3.3. 默认不支持删除主键操作，也不支持添加主键，添加自增索引

3.4. 目前不支持 DDL 变更合并的操作，目前对一个表进行多次 DDL，进行拆写

3.5 3.0.8(以上) 或 4.0 版本支持乐观事务和悲观事务

3.6 大表，比如超过 1 亿，建议每个 SQL 都要严格审核，否则一旦走错索引，可能会影响整个集群.（大表谨慎加索引）

3.7 表字段数不建议超过 60 个，建议单行的总数据大小不要超过 64K，数据长度过大字段最好拆到另外的表

3.8 不推荐使用复杂的数据类型

3.9 需要 join 的字段，数据类型保障绝对一致，避免隐式转换

3.10 WHERE 条件中不在索引列上进行数学运算或函数运算；

3.11 用 in /union 替换 or，并注意 in 的个数小于 300；

3.12 禁止使用 % 前缀进行模糊前缀查询。

3.13 TiDB 对大小写支持为 lower_case_table_names=2(只支持 2)

3.14 统计类 SQL 特别多，并行符合条件，建议使用 TiFlash

3.15 TiDB 不支持字段的有损变更。自增属性删除后不支持在新增自增属性。

3.16 库表索引等命名规则设计与 MySQL 一致即可

四 线上流程

4.1 必须在测试环境跑完 (兼容性测试，以及业务测试)，才可以考虑上生产。

4.2 至少 3 台物理机 (标 C 的机器，SSD 硬盘)，根据业务实际情况进行合理分配。

4.3 建议数据量特别大 (单表上亿)，有弹性扩、缩容，无法确认切分规则不能使用分库分表。

五 数据删除规范

5.1 删除表中全部的数据时，使用 TRUNCATE 而不要使用 delete。

5.2 如果大批删除，容易引发整个集群性能抖动。建议拆分 SQL（少删多提）

六 其他

6.1 大数据导入，联系 DBA 进行操作，导入成功后研发确认进行核对。

6.2 业务涉及的时候 如有热点表 热点读写等需要提前通知 DBA，对热点小表 还是建议存在 redis。

6.3 默认 GC 超时时间是 1 天 (tidb 默认 10 分钟)，可以恢复 1 天之前的数据。

6.4 定期针对慢 SQL 进行合理优化，默认统计信息收集时间 03 点到 05 点之间，如在期间有性能问题可联系 DBA 进行调整。如需要手动收集统计信息可以联系 dba。

6.5 TiDB 监控、报警、大事报 地址和报警配置 联系 dba 即可

6.6 线上默认版本 4.0. 最新 (大于 4.0.8)。如使用 3.0 版本的话默认 3.0. 最新 (大于 3.0.18)。自己单位内部订版根据实际情况选择。