先讲两个我亲手处理的线上事故。上个月帮一家电商客户做慢查询治理订单明细表不到 200 万行一个SUM(amount)的月度报表生成居然要 4.8 秒运营每次打开后台都够泡三杯咖啡。EXPLAIN 一看全表扫描确实跑不掉但真正让我后背发凉的是amount字段的类型——FLOAT。另一个客户更典型用户表phone是VARCHAR(11)业务代码里写的是WHERE phone 13800138000没加引号MySQL 偷偷把整列字符串转成数字比较十万行数据的查询硬是跑出 500 多毫秒。这两个事故一个栽在数据类型本身的精度缺陷一个栽在运算符触发的隐式转换恰好在MySQL 数据类型与运算符这个被大多数人当成入门基础的话题上。这一章我想讲透的不是教科书里的定义背诵而是商业项目里真正会咬人的那部分类型选错怎么烧钱运算符用不对会出什么诡异结果以及一套能落地执行的选型、排查、设计规范。内容偏实战适合刚写完 CRUD 想往数据库设计进阶的开发者、需要做表结构评审的 DBA以及被线上报表和慢查询折腾过一轮的业务后端。1. 线上事故复盘两个被数据类型坑惨的商业场景1.1 金额对不上账FLOAT 给报表埋的雷先说金额字段用FLOAT的教训。那个电商客户的订单表结构大概是这样的CREATE TABLE trade_order ( id INT PRIMARY KEY, order_no VARCHAR(32), amount FLOAT, created_at DATETIME );amount FLOAT看起来人畜无害毕竟单价 19.9、运费 0.1、优惠 0.2这些数在业务眼里再正常不过。但在计算机的二进制世界0.1 这个十进制小数是无法被精确表示的FLOAT存储的 19.9 实际上是 19.900000xxx。单条记录看不出差异一旦SUM()累加 200 万条订单误差就被放大成看得见的几块钱甚至几百块。财务手工账和系统导出各算各的对账永远差一口锅。我现场验证给团队看SELECT 0.1 0.2; -- 输出的不是 0.3而是 0.30000000000000004这个结果在DOUBLE下同样存在只是精度位数不同。所以商业系统里凡是跟钱沾边的字段规则只有一条用DECIMAL不要用FLOAT和DOUBLE。客户后来把amount改成DECIMAL(12,2)同一份月度报表从 4.8 秒降到 0.6 秒——不只是精度修复索引和统计信息也更干净了。顺带验证了一个常识FLOAT 的误差不是可能出错而是必然出错只是错误什么时候被SUM放大而已。1.2 手机号查询全表扫描隐式转换让索引失效第二个事故的主角是隐式转换。用户表phone字段是VARCHAR(11)开发在查询时写SELECT * FROM user WHERE phone 13800138000;注意右边是整数常量没带引号。MySQL 的比较规则里当字符串列和数字常量比较时会把字符串转成数字再比较。phone列存的是 13800138000 这种文本索引里维护的是字符串排序结构现在要求按数字匹配MySQL 只能把索引里的字符串一个个取出来做转换索引从快速查找退化成全量计算于是执行计划直接走typeALL。修复方式只是加一对引号SELECT * FROM user WHERE phone 13800138000;执行计划立刻变成typeref走idx_phone索引。这里想强调两点第一ORM 框架里如果实体字段声明成Integer拼接 SQL 时也可能不带引号排查时要会看最终发给 MySQL 的语句第二隐式转换不只发生在字符串和数字之间两张表关联时如果一边是utf8一边是utf8mb4同样会导致关联列无法高效走索引。这种索引明明存在却失效的案例排查起来比字段类型错误更隐蔽。2. 数值型选型指南从存储原理到业务边界2.1 整数族TINYINT 到 BIGINT你真的需要那么多位吗MySQL 整数类型有五个TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT。它们存储空间递增取值范围也递增选型的核心逻辑是用最小的空间装下业务绝对会出现的最大值并留出合理余量。类型字节有符号范围无符号范围典型业务用途TINYINT1-128 ~ 1270 ~ 255状态位、开关、逻辑删除标志SMALLINT2-32768 ~ 327670 ~ 65535库存数量、短代码、评分MEDIUMINT3-8388608 ~ 83886070 ~ 16777215中小规模自增IDINT4-2147483648 ~ 21474836470 ~ 4294967295常规主键、记数BIGINT8约 -9.22e18 ~ 9.22e180 ~ 约 1.84e19海量订单号、雪花ID很多开发者习惯一律INT(11)小到状态位大到订单号都是 INT。但状态位这种取值不超过几十个的字段用 TINYINT 就够了行数上千万时TINYINT 比 INT 每行省 3 个字节一个 5000 万行的状态表能省下约 143MB 存储B 树叶子节点能塞进更多行扫描时 I/O 也更低。还有一个被长期误解的概念TINYINT(1)里的(1)不是范围限制只是旧版本里的显示宽度MySQL 8.0.17 起已经废弃了显示宽度语法所以别再纠结TINYINT(1)和TINYINT(4)的区别。真正常见的坑是INT自增主键被业务跑满每秒几千订单的电商系统INT 的 21 亿上限看着远实际上两三年就能逼近。核心交易表的主键我建议直接上BIGINT或者用雪花ID方案的BIGINT不要等告警出来才改表。UNSIGNED的使用也要全家桶一致——主键用了无符号外键也必须无符号否则关联时会隐式转换索引效率打折扣。2.2 DECIMAL 的精确世界金额字段的规格设计与计算陷阱DECIMAL(M,D)里 M 是总位数D 是小数位数。例如DECIMAL(10,2)表示整数部分最多 8 位小数部分 2 位能存到 99999999.99。商业系统设计金额字段先想清楚两个问题最多可能出现多大的单笔金额以及中间计算需要保留几位小数。单笔金额刚上线的公司用DECIMAL(10,2)够用但做电商和跨境贸易订单金额可能膨胀我一般建议DECIMAL(12,2)起步整数部分 10 位约百亿级覆盖绝大多数国内业务。如果涉及汇率、折扣分摊、单价精度小数点后四位的情况则用DECIMAL(10,4)或者DECIMAL(14,4)存储展示层再ROUND成两位小数。为什么中间计算要保留更多小数位举一个真实场景一个订单里买三件商品总优惠 10 元按比例分摊到每个 SKU。如果每个 SKU 的分摊金额都在DECIMAL(10,2)上直接四舍五入三个数加起来大概率不等于 10 元差个一分两分最难受。正确做法是分摊计算用DECIMAL(10,4)或更高的精度最后一个 SKU 的分摊金额用总优惠金额 - 前 n-1 项之和倒挤出来保证总账永远平。另外DECIMAL上做除法要小心。MySQL 的/运算符结果会按参数精度扩展小数位直接用SELECT 100 / 3看到的是 33.3333业务上如果不需要这么高精度主动ROUND(100 / 3, 2)收敛。相比FLOAT的混乱DECIMAL 的行为是可控的这也是金融、电商、SaaS 计费系统都坚持 DECIMAL 的原因。2.3 浮点数的适用场景与精度兜底策略讲完 DECIMAL 的不可替代性也得客观说一句浮点数并非一无是处。FLOAT和DOUBLE的价值在于它们占用空间小、计算速度快适合不要求精确相等的场景——比如内容推荐的热度分数、商品评分均分、GPS 经纬度、用户行为统计的近似指标。举个例子一个商品评价的平均分 4.7 分用DOUBLE算出来可能是 4.700000000001但展示给用户时谁会看到小数点后第 10 位呢这类人类不需要精确到极致的数据浮点完全够用。反过来如果你必须用浮点做判断比如判断两个 GPS 坐标是否在同一个 50 米格子里不要直接用应该比较差值绝对值是否小于一个阈值比如ABS(a - b) 0.0001。浮点还有一个常用兜底策略存入数据库前先ROUND到固定的小数位数读取时再ROUND一次双保险。我在遗留系统里见过不少FLOAT字段它们往往已经绑定了大量历史数据没法一键改成 DECIMAL这种渐进修复的思路能先把错误率降下来。3. 字符串与日期时间业务建模的高频翻车区3.1 CHAR 与 VARCHAR 的取舍定长与变长的生意经CHAR(M)是定长字符串VARCHAR(M)是变长字符串。CHAR 存满 M 个字符不足的部分用空格填充读取时尾部空格会被去掉VARCHAR 额外用 1~2 字节记录实际长度只存有效内容。这里有一个容易误判的细节VARCHAR 的长度前缀是按字节数判断的不是按字符数。在utf8mb4字符集下一个字符最多占 4 字节所以VARCHAR(63)最大占用 252 字节长度前缀只要 1 个字节VARCHAR(64)最大占用 256 字节长度前缀就需要 2 个字节。这个差异对大多数单表性能影响可以忽略但在设计超宽表、联合索引时字节数直接决定索引是否超过上限值得心里有数。那么业务上到底用 CHAR 还是 VARCHAR我的原则是长度几乎固定的短代码用 CHAR比如订单状态码、国家代码、Y/N标志、手机号长度不固定的自然文本一律 VARCHAR。手机号是个好例子虽然看起来 11 位固定但如果你用 CHAR(11) 存某些客户端误传入的尾部空格在读取时会被吞掉虽然多数场景无感但严谨的系统还是建议 VARCHAR。归根结底CHAR 的优势是读写不需要处理长度前缀但代价是浪费存储VARCHAR 的优势是节省空间代价是每次读写多一步长度操作。几十万行看不出差距几千万行就要仔细算账了。3.2 大文本与 JSON别把所有内容都塞进 VARCHARVARCHAR 的上限是 65535 字节在utf8mb4下最多存 16383 个字符。很多新手一看到这个上限就把商品详情、日志内容、用户备注全塞进VARCHAR(5000)这是很糟糕的习惯。大文本应该用 TEXT 系列TINYTEXT 255 字节、TEXT 64KB、MEDIUMTEXT 16MB、LONGTEXT 4GB。用 TEXT 有四个需要知道的特性。第一历史版本中 TEXT 列不能设置默认值MySQL 8.0.13 之后才放开。第二TEXT 列无法直接在内存临时表中高效排序GROUP BY、ORDER BY 时可能走向磁盘临时表拖慢查询。第三给 TEXT 建索引只能建前缀索引比如INDEX(description(100))长度限制下注定无法用完整字段做等值匹配。第四ORM 映射到 Java 或 Python 时TEXT 类型经常要特殊处理比 VARCHAR 麻烦一点。所以我的建议是真正的大段内容才用 TEXT能截断存摘要或链接的别偷懒。JSON 类型是 MySQL 5.7 开始支持的特性它比VARCHAR 里存 JSON 字符串要可靠得多。用 JSON 类型能自动校验语法还能用JSON_EXTRACT()、JSON_UNQUOTE()、-这些函数高效取值。我在实际项目里会控制 JSON 字段的数量和大小只放高度动态、结构变化快的属性比如第三方渠道透传参数核心交易字段永远单独建模成列因为数据库的行式存储、索引、where 过滤都不是为整体 JSON 扫描设计的一个 JSON 字段塞太多业务逻辑最后坑的一定是自己。3.3 日期时间的四种类型与时区陷阱MySQL 表示时间的类型有 DATE、TIME、DATETIME、TIMESTAMP 四种它们的区别不搞清楚上线之后必有幺蛾子。类型字节范围特点DATE31000-01-01 ~ 9999-12-31只存日期TIME3-838:59:59 ~ 838:59:59时、分、秒DATETIME81000-01-01 00:00:00 ~ 9999-12-31 23:59:59与时区无关TIMESTAMP41970-01-01 00:00:01 UTC ~ 2038-01-19 03:14:07 UTC自动时区转换TIMESTAMP 存的是 UTC 秒数读取时根据数据库会话的time_zone转换成本地时间DATETIME 则原样存储你写进去几点就是几点。看起来能转时区是 TIMESTAMP 的优势但在分布式系统里各服务器时区配置不一致会导致数据显示混乱。我做全球购项目时吃过亏业务方要求按北京时间统计订单而数据库主机时区是 UTC直接用 TIMESTAMP 字段做日切永远差 8 小时。商业建议是业务含义明确的结算时间支付时间发货时间用 DATETIME并在写入前由应用层统一转成固定时区推荐 UTC 存储或统一北京时间记录创建时间、更新时间这种审计字段可以用 TIMESTAMP 搭配DEFAULT CURRENT_TIMESTAMP和ON UPDATE CURRENT_TIMESTAMP让数据库帮你维护。日期查询还有一个高频坑WHERE created_at BETWEEN 2024-01-01 AND 2024-01-31看着没问题其实漏掉了 1 月 31 日 23:59:59 之后的数据。稳妥写法是created_at 2024-01-01 00:00:00 AND created_at 2024-02-01 00:00:00用 下个月第一天保证闭区间完整也避免 DATETIME(3) 场景下微秒数据被切掉。3.4 默认值、字符集与排序规则的隐藏坑这里汇总几个我见过无数次的隐藏坑每一个都可能造成线上故障。第一个坑是 NULL 和默认值。很多开发习惯status INT DEFAULT NULL查询时还要写IS NOT NULL既别扭又慢。商业系统里绝大多数字段应该NOT NULL并给一个明确的默认值状态位TINYINT NOT NULL DEFAULT 0金额DECIMAL(12,2) NOT NULL DEFAULT 0.00时间DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP。搜索热词里有mysql 设置默认值为 0说的就是状态位默认 0 的实践0 通常表示初始态/未处理这样插入时不传也能保证语义完整。第二个坑是字符集排序规则。utf8mb4 在不同版本、不同库表之间混用常见问题就是关联查询走不了索引、ORDER BY排序结果不符合预期。排序规则utf8mb4_general_ci比较快但精度粗糙utf8mb4_unicode_ci更符合 Unicode 语义utf8mb4_bin区分大小写。我的做法是新库统一utf8mb4 utf8mb4_0900_ai_ciMySQL 8.0 默认老库统一utf8mb4_general_ci重点是全链路一致。如果一个字段同时被业务当唯一标识用比如会员卡号大小写不敏感的规则下ABC123和abc123会触发唯一键冲突这时就要果断选utf8mb4_bin。第三个坑是TINYINT(1)显示宽度误导前面提过 MySQL 8.0.17 已废弃。总之看一个字段的真实类型永远用SHOW FULL COLUMNS FROM table不要只看 Navicat 里显示的字段名和注释。4. 运算符体系拆解SQL 表达式的拼图4.1 算术运算符报表计算别忽略 DIV 和 MODMySQL 的算术运算符包含、-、*、/、DIV、%、MOD。大多数人对加减乘除很熟但对DIV和MOD的细节不够敏感。/是浮点除法SELECT 5 / 2返回 2.5000DIV是整数除法SELECT 5 DIV 2返回 2。%和MOD都是取余等价使用。需要注意负数取余的符号在 MySQL 中结果跟随被除数比如SELECT -5 % 2返回 -1SELECT 5 % -2返回 1。这个规则在不同数据库里不一致跨库迁移时要特别小心。商业报表里DIV常用于批次计算、页码分桶MOD常用于取模分片、奇偶分流。比如订单号是雪花生成的BIGINT按订单号MOD 8可以均匀地把订单划分到 8 个处理线程这在异步任务里很实用。算术运算符还有一个值得注意的地方SUM(amount) / COUNT(*)求客单价时如果amount是 DECIMAL结果的分母是整数除法结果会保留很高的小数位展示前记得ROUND成两位小数。4.2 比较运算符与 NULL 三值逻辑的暗礁比较运算符有、!、、、、、、BETWEEN ... AND ...、IN、IS NULL、等。最容易翻车的是 NULL 的三值逻辑SQL 中的比较结果除了 TRUE 和 FALSE还有 UNKNOWNNULL。举个例子WHERE salary NULL永远查不到任何行因为salary NULL的结果是 UNKNOWNWHERE 只接受 TRUE。必须写WHERE salary IS NULL。更隐蔽的是NOT IN子查询返回 NULL 的情况SELECT * FROM order WHERE customer_id NOT IN ( SELECT customer_id FROM blacklist WHERE flag 1 );如果blacklist表中存在customer_id IS NULL的行NOT IN的整体结果会是空——因为customer_id NOT IN (NULL)无法判断真伪。这种问题的排查思路是尽量别让子查询结果里出现 NULL要么在子查询里过滤WHERE customer_id IS NOT NULL要么改写为NOT EXISTS。是安全等于它能正确比较 NULLNULL NULL返回 1。我一般只在确实需要处理 NULL 的等值判断时用它普通查询不需要。还有一个比较运算符的坑字符串和数字比较时比如WHERE mobile 13800138000会触发隐式转换我在第 1 节已经复盘过。另外9 10在字符串比较下是 TRUE因为按字典序先比第一个字符9 大于 1业务里如果字段存的是字符串数字排序和比较都会符合字典序而非数值序这是设计问题不是运算符的问题。4.3 逻辑运算符优先级与短路评估的实战价值逻辑运算符的优先级从高到低是NOTANDOR这是 SQL 新手最常见的心理盲区。看这个条件WHERE status 1 OR status 2 AND pay_time 2024-01-01因为AND优先级更高实际含义是status 1 OR (status 2 AND pay_time ...)如果业务原意是status 为 1 或 2且支付时间在年初之后就必须加括号WHERE (status 1 OR status 2) AND pay_time 2024-01-01在存储过程或 ORM 动态拼接里这种优先级问题尤其容易躲过 Code Review因为肉眼看不出语义。我的建议是多条件组合一律显式加括号不依赖优先级记忆。还有一个反直觉的点SQL 不保证短路求值。在编程语言里a 0 1/a 1可以避免除零但在 SQL 里 MySQL 优化器可能重排条件的计算顺序你以为前面不成立后面就不会执行实际不一定。所以在 SQL 里不要写x 0 AND 1/x 1这种依赖求值顺序的精巧表达式要么拆成两条语句要么用CASE WHEN先把分母处理干净。这是我从一次报表任务报错里换来的教训优化器把条件顺序一调除零错误就冒出来了。XOR用得少但偶尔会在逻辑互斥判断里出现比如仅当两个条件中有且只有一个成立时过滤。它的语义清晰不过可读性差商业 SQL 我建议用OR加括号替代方便后人维护。4.4 位运算符、正则运算符的冷门但实用场景位运算符、|、^、~、、在业务 SQL 里不常用但我见过一个经典场景用一个 INT 字段做权限位的位掩码。比如priv 1表示读、priv 2表示写、priv 4表示删除判断某个用户是否有删除权限就写WHERE priv 4 4设置只读删除权限就UPDATE ... SET priv priv | 5。位掩码的优点是紧凑一个 TINYINT 能表达 8 种独立权限缺点是 SQL 可读性差而且位运算基本无法走索引数据量大时查询效率堪忧。如果只是判断奇偶WHERE id 1 1比MOD(id, 2) 1在某些场景下更快但这类微优化对商业系统意义不大不建议为了炫技引入。正则运算符REGEXP和RLIKE等价。它在数据质量核对时很好用比如验证手机号格式SELECT * FROM user WHERE phone REGEXP ^1[0-9]{10}$;但它有两个硬伤一是REGEXP不走索引全表扫描二是和 LIKE 不同它没有专门的索引优化手段。所以线上业务查询不要依赖它只在离线数据清洗和单次排查中使用。BETWEEN ... AND ...的边界是包含两端的。日期范围查询时如果写成BETWEEN 2024-01-01 AND 2024-01-31隐含只到 2024-01-31 00:00:00因为中间值是一个 DATETIME。这个我在 3.3 节提过正确写法这里再从运算符角度强调一遍能用半开区间就用半开区间[start, next_start)少用闭区间。5. 商业项目中的类型与运算符协同设计5.1 订单统计口径设计日期范围与状态机联动商业报表里最典型的场景就是月度订单统计。假设表结构经过前面几节的修正金额是DECIMAL(12,2)支付时间是DATETIME订单状态是TINYINT那么一份月底对账 SQL 可以这样写SELECT DATE_FORMAT(pay_time, %Y-%m) AS month, COUNT(*) AS paid_orders, ROUND(SUM(pay_amount), 2) AS revenue, ROUND(SUM(pay_amount) / COUNT(*), 2) AS avg_order_value FROM trade_order WHERE pay_time 2024-01-01 00:00:00 AND pay_time 2025-01-01 00:00:00 AND order_status IN (2, 3) -- 2:已支付 3:已完成 GROUP BY DATE_FORMAT(pay_time, %Y-%m) ORDER BY month;这里有两个设计意图要说清楚。第一日期筛选用和而不是BETWEEN是刻意避免边界丢数DATE_FORMAT(pay_time, %Y-%m)在 GROUP BY 里会让索引失效但月报表本身要扫全月数据这个代价可以接受。第二ORDER_STATUS IN (2, 3)里的状态码是 TINYINT 整数常量不会触发隐式转换如果状态字段是 VARCHAR就要保证右侧是字符串2、3否则又踩第 1 节讲的坑。我经常看到团队在统计报表里直接用WHERE order_status 2 OR order_status 3既啰嗦又容易和后面其他条件混在一起犯优先级错误IN才是更清晰的表达。5.2 优惠分摊与百分比精度控制优惠分摊是电商财务里面最容易出尾差的一个环节。假设一张订单总优惠 10 元要按三个 SKU 的实付金额比例分摊到退款单上。中间计算必须用高精度存储也必须用 DECIMAL否则账目对不上。推荐的做法是把中间结果设计成DECIMAL(10,4)分摊时先算出前两个 SKU 的分摊金额并ROUND到分最后一个 SKU 分摊金额用倒挤-- 伪 SQL示意逻辑 SET rate1 ROUND(total_sku1 / order_total, 4); -- 保留4位小数的分摊率 SET alloc1 ROUND(discount_total * rate1, 2); SET alloc2 ROUND(discount_total * ROUND(total_sku2 / order_total, 4), 2); SET alloc3 discount_total - alloc1 - alloc2; -- 末位倒挤倒挤法虽然让最后一个 SKU 背上全部尾差但总账一定平这在财务上是可解释、可审计的。如果哪天发现退款分页数据对不上先看中间结果是不是用了FLOAT再看最后一个 SKU 有没有做倒挤。百分比存储也可以用DECIMAL(5,4)表示 0.1500 这样的折扣率而不要用FLOAT存0.15。5.3 跨库迁移的类型映射从 Oracle/SQL Server 到 MySQL很多商业项目是从 Oracle 或 SQL Server 迁到 MySQL 的。类型映射表放这里方便大家直接抄OracleSQL ServerMySQL说明NUMBER(10,2)DECIMAL(10,2)DECIMAL(10,2)金额/小数NUMBER(19,0)BIGINTBIGINT大整数VARCHAR2(n)NVARCHAR(n)VARCHAR(n)字符语义注意字节计算DATE含时间DATETIME2DATETIMEOracle 的 DATE 包含时分秒TIMESTAMP(6)DATETIME2(6)DATETIME(6)微秒精度CLOBNVARCHAR(MAX)MEDIUMTEXT / LONGTEXT大文本BLOBVARBINARY(MAX)BLOB二进制Oracle 里的NUMBER如果不指定精度迁移时不要懒省事统一换成DECIMAL(65,30)那个字宽的索引效率很糟糕。正确做法是根据业务列的实际最大值重新定精度或者归并到BIGINT。VARCHAR2 的 n 是字符还是字节要核对MySQL 这边 VARCHA R 的 M 是字符上限语义差别会导致长度超出、写入报错。迁移之后一定要复查表级、字段级、连接级字符集统一否则历史数据和新增数据一 JOIN 就出乱子。5.4 字符集与排序规则跨表关联的性能前提跨表关联除了类型要一致字符集和排序规则也必须一致这是我在 3.4 节埋下的线头这里展开讲商业影响。两个表 JOIN 时如果user.phone VARCHAR(11) utf8mb4_general_ci和member.phone VARCHAR(11) utf8mb4_binMySQL 需要找到能兼容两者的排序规则来比较。它能找到的时候关联列可能无法使用索引找不到的时候直接报Illegal mix of collations错误。这在多库多表的大型系统里并不罕见因为不同团队负责的表用了不同版本默认值。快速排查方法查询information_schema.COLUMNS里所有业务表的字符集和排序规则SELECT TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, CHARACTER_SET_NAME, COLLATION_NAME FROM information_schema.COLUMNS WHERE TABLE_SCHEMA your_db AND CHARACTER_SET_NAME IS NOT NULL ORDER BY TABLE_NAME, ORDINAL_POSITION;扫出不一致的字段统一改成目标排序规则。注意改排序规则会用锁生产环境要避开高峰窗口或者用在线 DDL 工具。别小看这一步我遇到过一次运营后台的左连接查询时快时慢最后定位到就是两个表 phone 字段排序规则不一致改了之后查询时间从秒级回到毫秒级。6. 我沉淀的十项设计规范与排查经验6.1 建表类型选型清单商业项目重新设计表结构或者做新库评审时我通常会按下面这份清单过一遍每一条都来自真实踩坑记录。第一整数类型按够用且留余量选。状态、枚举用 TINYINT常规计数用 INT海量主键、雪花ID用 BIGINT不用 MEDIUMINT 这种冷门类型。第二金额一律 DECIMAL默认DECIMAL(12,2)涉及汇率和折扣分摊用DECIMAL(10,4)。第三小数位数明确的比率用 DECIMAL比如DECIMAL(5,4)。第四订单号、支付单号、流水号统一VARCHAR(32)或BIGINT不要混用。第五业务时间用 DATETIME审计时间用 TIMESTAMP DEFAULT CURRENT_TIMESTAMP。第六状态字段TINYINT NOT NULL DEFAULT 0主流程用 0/1/2 整数不要用字符串写paid省空间也省索引。第七所有字段优先NOT NULL确实存在未设置语义时加 DEFAULT 而不是留 NULL或者单独用 0/空串表达。第八字符串字段不需要大文本的一律 VARCHAR评论正文、备注用 TEXT 但要评估是否建前缀索引。第九JSON 字段保留给极动态属性核心业务字段独立成列。第十字符集和排序规则全局统一utf8mb4大小写敏感场景单独使用utf8mb4_bin或utf8mb4_0900_as_cs。6.2 慢查询与索引失效的定位流程遇到线上慢查询我建议按这条链路排查能省一大半时间。先看执行计划EXPLAIN SELECT * FROM user WHERE phone 13800138000; EXPLAIN SELECT * FROM user WHERE phone 13800138000;对比type从ALL变成refkey从 NULL 变成idx_phone就基本确认是隐式转换问题。再看Extra列出现Using where但没用索引往往就是条件列被函数包住或者类型转换了出现Using filesort说明ORDER BY字段排序规则或索引顺序不对。如果执行计划看不出问题就去查表结构SHOW FULL COLUMNS FROM user; SHOW CREATE TABLE user;重点看三件事字段类型是否和查询条件匹配字符集排序规则是否统一索引是否覆盖 where 条件。还查不出来的开慢日志SET GLOBAL slow_query_log ON; SET GLOBAL long_query_time 1;慢日志会把超过 1 秒的语句打出来配合mysqldumpslow排序就能把问题语句批量捞出来逐一分析。6.3 一些不成文的实践经验最后分享几条我自己的操作习惯未必有教科书依据但非常实用。第一不要相信以后数据量大了再优化。数据库字段类型设计是最难在后期变更的东西之一一张 5000 万行的表要从 VARCHAR 改成 TEXT 或 INT 改成 BIGINT锁表时间和回滚成本都极高。宁可设计时多想十分钟给未来留足空间。第二用 ORM 时注意类型映射。Java 的BigDecimal对应 DECIMALLong对应 BIGINTInteger对应 INTPython 的Decimal同样要映射 DECIMAL。ORM 层的不当映射会让 SQL 层的隐式转换问题潜伏起来排查时记得看真实 SQL 而不是只看 ORM 代码。第三Navicat 这类可视化工具看字段很方便但我做正式变更前一定会回SHOW CREATE TABLE确认底层真实类型尤其是 TINYINT(1)、INT(11) 这类显示宽度容易让人误判的字段。生产环境结构变更用内存表或在线 DDL 工具评估锁表风险别在高峰期直接 ALTER。数据类型和运算符的价值不在定义本身而在每一次慢查询、每一分对不上的账、每一个线上告警里。我的小习惯是每接手一个新项目先花半小时把所有核心表的SHOW CREATE TABLE过一遍把字段类型和业务规模对照检查。这个习惯替我避开了太多以后再说的雷。建表时多想两分钟性能和账目问题都会离你远一点。