对象命名规范

表设计规范

表需要有主键或者非空唯一索引，以便兼容周边复制工具。
业务表使用自增主键时，字段类型推荐使用 bigint unsigned。
出于性能考虑，尽量避免存储超宽表，数据长度过大的字段最好拆到独立的表存储，建议表字段数不超过 60 个，建议单行的总数据大小不要超过 64K，单行的总数据大小强制不超过 6 MB。
不推荐使用复杂的数据类型，如 blob 或者 json。
进行 join 的关联字段，数据类型保证一致，避免隐式转换。
不能以范式作为唯一标准或者指导，在设计过程中，需要从实际需求出发，以性能提升为根本目标。为了提升性能减少表关联，可以适当保存冗余数据做反范式设计。
表对象的设计请注意单个 Table 的限制。Columns 的最大限制可通过 table-column-count-limit 修改；Indexs 的最大限制可通过 index-limit修改。

所有整数类型的字段推荐只使用 INT 或者 BIGINT。
浮点类型推荐使用 DECIMAL 。
时间字段使用时间日期类型，不要使用字符串类型存储。
所有需要精确到时间(时分秒)的字段均使用 DATETIME，不要使用 TIMESTAMP 类型。
仅当字符数量可能超过 20000 个的时候，才建议使用TEXT类型来存放字符类数据。所有使用 TEXT 类型的字段建议和原表进行分拆，与原表主键单独组成另外一个表进行存放。
不建议使用 ENUM、SET 类型，尽量使用 TINYINT 来代替。

选择区分度大的列建立索引，不在低基数列上建立索引。低基数列如：性别，是否是 XXX。
单张表的索引数量控制在 5 个以内，避免索引冗余。
索引中的字段数建议不超过 5 个。
唯一索引建议由 3 个或更少的字段组成。
尽量不要在频繁更新的列上创建索引。
尽可能地将使用频率高的，经常被点查使用的列排在复合索引靠前的位置，将经常进行范围查询的列排在后面。
很长的 VARCHAR 字段建立索引时，指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度即可，例如 idx_table_name (name(10))。
定期删除长时间未使用过的索引。
ORDER BY，GROUP BY，DISTINCT 的字段需要添加在索引的后面，形成覆盖索引。
新的 select, update, delete 上线，都要先执行 explain 命令，观察执行计划是否有异常情况发现，以确保索引的正确性。
不建议在 where 条件索引列上使用函数，会导致索引失效，如 lower(email)。
业务语句中使用 like 模糊匹配时 % 不要放首位，以免导致索引失效，或者使用时结合其他有效的约束条件。

多表关联应该显式使用 join 子句，避免漏掉关联条件，造成笛卡尔积。
嵌套SQL语句应该为不同表指定不同别名。
高并发交易场景，单条语句关联表不超过两张，使用执行计划为 IndexJoin 的多表关联语句，外表建立了正确的条件过滤索引，内表建立了正确的关联和条件过滤索引。
低并发的分析场景，单条语句关联表不超过 10 张，其中亿级表不超过 2 张。

单个事务的总大小默认不超过 100 MB，最大支持 10 GB，实际的单个事务大小限制还取决于服务器剩余可用内存的大小，执行事务时计算节点进程的内存消耗大约是事务大小的 6 倍以上。
由于执行事务时计算节点进程的内存消耗大约是事务大小的 6 倍以上，事务设置过大，或者 Batch 过高，可能导致计算节点进程 OOM，需要评估好内存容量。
为了使性能达到最优，需要对大事务按某个业务维度进行拆分，每 100～500 行提交一个事务。

对于写入量非常大的表，应当通过应用性能压测等方法在测试环境模拟表的热点情况。
通过以下三种手段进行配置，规避表的主键写入热点。
- 避免连续自增主键的设计，建议采用雪花算法生成 UUID 主键。
- 主键是非整数的表或者启用 alt-primarykey=true 配置后创建的所有表，使用 SHARD_ROW_ID_BITS 语法创建基于 rowid 的分片方案，例如：CREATE TABLE t (c int) SHARD_ROW_ID_BITS = 4 或 ALTER TABLE t SHARD_ROW_ID_BITS = 4。
- 创建按照 Hash 或 Range 分区表避免热点。