数据库数据类型选型实战：精度、时区与跨库兼容性指南

1. 为什么说数据类型不是“贴标签”，而是数据库的“操作系统内核”？

刚接触 SQL 的人，常把VARCHAR(50)当成给字段起个“昵称”——就像给 Excel 单元格加个备注：“这里填名字”。但这种理解，离真实场景差了整整一个数据库引擎的距离。我带过几十个刚转行的新人，几乎所有人都在入职第三周左右栽在同一类坑里：明明逻辑没错，SELECT * FROM orders WHERE amount > 1000却查不出结果；或者导出报表时，金额列突然变成999.9999999999999；又或者两个系统对接时，'2024-03-15'在 A 库能查，在 B 库直接报错。问题根源，90% 出在数据类型选错了。

数据类型根本不是标签，它是数据库执行所有操作的底层契约。它决定了：

• 存储层：这个值在磁盘上占多少字节、怎么排列（比如INT是 4 字节二进制补码，DECIMAL(10,2)是按整数+小数位分别编码）；
• 计算层：10 + '5'在 MySQL 里会隐式转成15，在 PostgreSQL 里直接报错，因为BOOLEAN和TEXT的隐式转换规则完全不同；
• 索引层：VARCHAR(255)和VARCHAR(100)建 B-Tree 索引时，前者节点分裂更频繁，查询慢 15%～20%（我们线上订单表实测过）；
• 网络层：TIMESTAMPTZ传到应用端是带时区的2024-03-15T09:30:00+08:00，而TIMESTAMP只传2024-03-15 09:30:00，Java 的LocalDateTime接收后者会丢时区信息，导致跨时区订单时间全乱。

你写的每一行CREATE TABLE，本质是在给数据库下指令：“请用这套规则管理我的数据”。它不像编程语言里的变量声明，声明完就完了；它是持续生效的约束力，贯穿插入、查询、索引、备份、主从同步全过程。我见过最痛的教训，是某电商把用户手机号存成INT，结果遇到13800138000这种以1开头的号——MySQL 的INT最大值是2147483647，13800138000直接溢出变负数，用户登录时密码校验永远失败。排查了三天，最后发现建表语句里写着phone INT NOT NULL。

所以这本指南不讲“有哪些类型”，而是带你钻进数据库的血管里，看数据类型怎么真正影响你的每一行代码、每一次查询、每一分性能。我会用真实生产环境的案例、可复现的 SQL 脚本、跨三大主流数据库（MySQL 8.0 / PostgreSQL 15 / SQL Server 2019）的对比实验，告诉你：

• 为什么DECIMAL(10,2)存钱比FLOAT少踩 3 类致命坑；
• 为什么VARCHAR(100)比VARCHAR(255)在千万级用户表里省下 12GB 存储；
• 为什么DATE和DATETIME混用会让 BI 报表凌晨 3 点的数据消失；
• 以及最关键的——当你接手一个老系统，如何用 5 分钟 SQL 快速诊断出数据类型设计的硬伤。

适合谁读？如果你写过INSERT INTO users VALUES (...)，但没想过users.name为什么是VARCHAR(50)而不是VARCHAR(255)；如果你调过WHERE created_at > '2024-01-01'，但不知道'2024-01-01'是字符串还是日期字面量；如果你被Column 'status' cannot be null报错卡住过，却只想着加DEFAULT 'active'而不是检查status该不该是ENUM或BOOLEAN——那这篇就是为你写的。接下来的内容，没有一句废话，全是我在金融、电商、SaaS 项目里亲手验证过的结论。

2. 数据类型四大核心分类：原理、选型逻辑与跨库差异解剖

2.1 数值类型：精度即正义，存储即成本

数值类型绝不是“数字就用 INT，带小数点就用 FLOAT”这么简单。它的选择直接决定你的财务系统会不会算错一分钱，科学计算会不会累积误差，甚至影响服务器采购预算。我拆解三个关键维度：精度需求、范围预估、存储开销。

先说最典型的陷阱：用 FLOAT 存钱。新手看到salary DECIMAL(10,2)觉得麻烦，改用salary FLOAT。表面看55000.00插进去显示一样，但执行SELECT salary * 0.1 FROM employees WHERE id = 1，MySQL 可能返回5499.999999999999，PostgreSQL 返回5500.0，SQL Server 返回5500.000000000000。为什么？因为FLOAT遵循 IEEE 754 标准，用二进制近似表示十进制小数。0.1在二进制里是无限循环小数（就像十进制的1/3 = 0.333...），必须截断，误差在计算中会放大。我们曾有个支付对账脚本，用FLOAT算手续费，百万笔交易累计误差达 237.8 元，审计直接叫停。

正确方案是DECIMAL(p,s)或NUMERIC(p,s)（二者在标准 SQL 中等价）。p是总位数，s是小数位数。例如DECIMAL(10,2)表示最多 10 位数字，其中 2 位小数，能存99999999.99。它内部把数字当整数处理（存9999999999），再除以10^2，完全避免二进制误差。但代价是存储更大：DECIMAL(10,2)占 5 字节，FLOAT只占 4 字节。所以原则很明确：只要涉及金钱、比例、精确计数（如库存数量），必须用 DECIMAL/NUMERIC；只有科学计算、传感器原始数据等允许微小误差的场景，才考虑 FLOAT/DOUBLE。

再看整数类型。很多人无脑用BIGINT（8 字节），觉得“以后数据多了不怕”。但实际业务中，用户 ID 用INT（4 字节）足够支撑 42 亿用户；订单号用BIGINT是因为要支持分库分表后全局唯一。关键在范围预估：

• TINYINT（1 字节）：范围 -128~127，适合状态码（0=待处理,1=成功,2=失败）；
• SMALLINT（2 字节）：-32768~32767，适合省份编号、商品分类 ID；
• INT（4 字节）：-2147483648~2147483647，覆盖 99% 的主键和计数场景；
• BIGINT（8 字节）：-9223372036854775808~9223372036854775807，仅用于超大规模 ID 或时间戳（毫秒级）。

提示：MySQL 的TINYINT(1)常被误认为“布尔型”，但它本质还是整数。TINYINT(1)只是显示宽度提示，存2完全合法。真要布尔，PostgreSQL 用原生BOOLEAN（存true/false），SQL Server 用BIT（存0/1），MySQL 5.7+ 推荐用TINYINT(1)但需应用层强校验，或升级到 8.0+ 用BOOLEAN别名（实际仍是TINYINT）。

跨库差异最明显的是无符号整数。MySQL 支持INT UNSIGNED（0~4294967295），PostgreSQL 用SERIAL（自动INTEGER）不支持无符号，SQL Server 用INT但可通过CHECK约束模拟。这意味着：如果你的 MySQL 表用id INT UNSIGNED AUTO_INCREMENT，迁到 PostgreSQL 时，要么改id SERIAL（自动INTEGER），要么手动建id BIGSERIAL并设CHECK (id >= 0)。我们迁移一个 20 亿记录的用户表时，就因忽略这点，导致主键冲突重跑三天。

2.2 字符串类型：长度不是数字游戏，而是性能开关

字符串类型的选择，直接影响查询速度、存储空间、甚至应用层代码复杂度。核心矛盾在于：固定长度 vs 可变长度，确定长度 vs 不确定长度。

CHAR(n)是固定长度。比如country_code CHAR(2)，存'US'时实际占 2 字节，存'CN'也占 2 字节。优势是存储和检索极快（数据库直接按偏移量读），劣势是浪费空间（存'A'也占 2 字节）。适用场景极少：全球国家代码（ISO 3166-1 alpha-2）、货币代码（ISO 4217）、机场三字码（IATA）。我们做过测试：在 1 亿行的订单表里，currency CHAR(3)比currency VARCHAR(3)查询快 8%，但存储多占 1.2GB。所以除非是高频查询且长度绝对固定，否则别碰CHAR。

VARCHAR(n)是可变长度。n是最大长度，实际存多少占多少字节，外加 1~2 字节记录长度。比如name VARCHAR(100)，存'Alice'占 5+1=6 字节，存'Alexander the Great'（19 字符）占 19+1=20 字节。关键点在于：n不是越大越好。MySQL 5.7+ 对VARCHAR的n有严格限制：单行总长度不能超 65535 字节。如果定义VARCHAR(20000)，再加几个字段，很容易超限报错。更隐蔽的问题是排序和临时表：ORDER BY name时，MySQL 会把name全字段加载到内存排序，VARCHAR(255)比VARCHAR(100)多占 155 字节内存，10 万行排序就多用 15MB 内存，可能触发磁盘临时表，速度暴跌 5 倍。我们优化一个报表查询，把product_name VARCHAR(255)改成VARCHAR(120)，内存占用从 2.1GB 降到 1.3GB，查询从 47 秒降到 8 秒。

TEXT和CLOB是大文本专用。TEXT在 MySQL 中最大 64KB，PostgreSQL 中无硬限制（实际受toast表限制），SQL Server 中VARCHAR(MAX)最大 2GB。它们不参与内存排序（数据库会用磁盘临时表），所以ORDER BY description会极慢。正确做法是：大文本只用于存储，查询时用SUBSTRING(description, 1, 200)截取摘要，或单独建全文索引。我们有个日志表，log_content TEXT，原本WHERE log_content LIKE '%error%'全表扫描 2 分钟，加FULLTEXT(log_content)后降到 0.3 秒。

Unicode 支持是另一道坎。VARCHAR默认是数据库字符集（如 MySQL 的utf8mb4），但NVARCHAR（SQL Server）和NCHAR显式声明 Unicode。区别在于：VARCHAR存中文需要utf8mb4字符集支持 4 字节 UTF-8，而NVARCHAR强制用 UCS-2（2 字节）或 UTF-16（可能 4 字节），兼容性更好但存储翻倍。我们对接一个日本客户系统，他们用NVARCHAR存𠮷（U+20BB7，需 4 字节 UTF-8），MySQLVARCHAR必须设utf8mb4，否则存成?。结论：如果业务涉及多语言（尤其中日韩、emoji），MySQL 用utf8mb4 + VARCHAR，SQL Server 用NVARCHAR，PostgreSQL 用TEXT（默认 UTF-8）。

2.3 日期时间类型：时区不是可选项，而是必答题

日期类型选错，轻则报表时间错 8 小时，重则订单丢失、风控失效。核心误区是：以为DATETIME和TIMESTAMP只是“存得更多”或“存得更少”。

DATE只存日期（YYYY-MM-DD），TIME只存时间（HH:MM:SS），DATETIME存日期+时间（YYYY-MM-DD HH:MM:SS），TIMESTAMP也存日期+时间，但本质是时间戳（Unix Epoch 毫秒数）。关键差异在时区处理：

• DATETIME是“字面量”，存什么就是什么。INSERT INTO t VALUES ('2024-03-15 10:00:00')，无论服务器时区是 UTC+8 还是 UTC-5，查出来永远是2024-03-15 10:00:00；
• TIMESTAMP是“相对值”，存入时会转成 UTC 时间戳，查询时再转回当前会话时区。SET time_zone='+00:00'; INSERT INTO t VALUES ('2024-03-15 10:00:00')存的是 UTC 时间；SET time_zone='+08:00'; SELECT * FROM t查出来是2024-03-15 18:00:00。

这导致经典问题：一个部署在新加坡（UTC+8）的系统，用DATETIME存用户注册时间，运维半夜切到美国西海岸（UTC-7）服务器，所有历史时间显示错 15 小时。而用TIMESTAMP，只要会话时区设对，显示永远正确。但TIMESTAMP有范围限制（MySQL 是 1970~2038 年），DATETIME是 1000~9999 年。所以原则是：记录事件发生时间（如订单创建、日志时间），用TIMESTAMP（或 PostgreSQL 的TIMESTAMPTZ）；记录固定日期（如生日、合同到期日），用DATE；记录纯时间（如营业时间），用TIME。

TIMESTAMPTZ（PostgreSQL）和DATETIMEOFFSET（SQL Server）是终极方案，它们把时区信息和时间一起存。'2024-03-15 10:00:00+08'存进去，查出来还是带+08。我们做跨境支付系统时，强制所有时间字段用TIMESTAMPTZ，应用层 Java 用OffsetDateTime接收，彻底规避时区混乱。MySQL 8.0+ 的TIMESTAMP已支持时区，但语法不如 PostgreSQL 直观。

2.4 特殊类型：JSON、UUID、数组——不是炫技，而是解决真实瓶颈

特殊类型常被当成“高级功能”，其实它们是为了解决传统关系模型的硬伤。关键看是否满足：结构不确定、嵌套深、查询频率低但写入频繁。

JSON类型（MySQL 5.7+/PostgreSQL/SQL Server 2016+）本质是校验过的字符串，但提供->、->>操作符快速提取字段。比如用户配置表：

CREATE TABLE user_settings ( id INT PRIMARY KEY, config JSON ); INSERT INTO user_settings VALUES (1, '{"theme":"dark","notifications":{"email":true,"sms":false}}'); SELECT config->>'$.theme' AS theme FROM user_settings; -- 返回 "dark"

优势是：不用为每个配置项建列，新增push_token字段无需ALTER TABLE；劣势是：无法为 JSON 内部字段建索引（MySQL 5.7+ 支持生成列索引，但复杂）。我们曾用JSON存用户设备信息（iOS/Android/版本号），但后来发现WHERE config->>'$.os' = 'iOS'全表扫描太慢，最终拆成os VARCHAR(20), os_version VARCHAR(20)两列，查询提速 20 倍。所以JSON适用场景是：配置项、日志详情、第三方 API 原始响应体——这些字段你基本不按它查，只按 ID 查后解析。

UUID（通用唯一标识符）解决自增 ID 的三大痛点：

• 安全暴露：id=100001让爬虫知道这是第 10 万零一个用户；
• 分库分表：自增 ID 在不同库可能重复；
• 离线生成：APP 端可生成 UUID 后异步提交，不依赖数据库。
  但代价是：UUID占 36 字符（字符串）或 16 字节（二进制），比BIGINT（8 字节）大一倍，B-Tree 索引更臃肿。MySQL 8.0+ 支持UUID_TO_BIN()将35a2b5e8-1f9c-4a2d-8e1a-3c5b7d9e1f2a转成 16 字节二进制，索引效率接近BIGINT。我们所有新微服务都用BINARY(16)存 UUID，SELECT * FROM orders WHERE id = UUID_TO_BIN('xxx')，性能损失不到 5%。

ARRAY（PostgreSQL 专属）是真正的杀手锏。比如权限系统：用户有多个角色，传统方案是user_roles关联表，查一个用户所有角色要JOIN。用ARRAY：

CREATE TABLE users ( id SERIAL PRIMARY KEY, name VARCHAR(100), roles TEXT[] DEFAULT ARRAY['user']::TEXT[] ); INSERT INTO users (name, roles) VALUES ('Alice', ARRAY['admin','editor']); SELECT * FROM users WHERE 'admin' = ANY(roles); -- 直接查，无需 JOIN

ANY操作符让数组查询像普通字段一样快。我们用它重构了 SaaS 系统的租户权限，QPS 从 1200 提升到 3500。但注意：ARRAY不是万能的，更新单个元素要UPDATE ... SET roles = array_replace(roles, 'old', 'new')，比关联表UPDATE user_roles SET role='new' WHERE user_id=1 AND role='old'复杂。所以原则是：读多写少、元素数量稳定（< 100）、不需对单个元素建索引的场景，用 ARRAY。

3. 实操指南：从建表到调优，手把手构建健壮数据模型

3.1 建表黄金七步法：拒绝拍脑袋定类型

我带团队写建表语句，严格执行七步法，杜绝“先建再改”的返工。每一步都有明确检查点，下面用电商订单表orders为例演示：

第一步：明确业务实体与核心属性
订单实体包含：订单号、用户 ID、商品列表、总金额、状态、创建时间、支付时间。注意“商品列表”是嵌套结构，不是原子字段。

第二步：逐字段分析数据特征

• order_no：全局唯一，长度 20 字符（如ORD2024031500001），非数字，不可为空；
• user_id：关联用户表，整数，范围预估 1~5 亿，需索引；
• items：商品列表，JSON 格式（含商品 ID、数量、单价），不用于查询条件；
• total_amount：金额，精确到分，范围 0.01~999999.99；
• status：状态码，枚举值pending/paid/shipped/cancelled，共 4 种；
• created_at：订单创建时间，需精确到秒，跨时区；
• paid_at：支付时间，可能为空（未支付订单）。

第三步：匹配数据类型并标注理由

第四步：设置约束与默认值

-- PostgreSQL 示例 CREATE TABLE orders ( id SERIAL PRIMARY KEY, order_no VARCHAR(20) NOT NULL UNIQUE, user_id BIGINT NOT NULL REFERENCES users(id), items JSON NOT NULL, total_amount DECIMAL(10,2) NOT NULL CHECK (total_amount >= 0), status VARCHAR(20) NOT NULL DEFAULT 'pending', created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(), paid_at TIMESTAMPTZ NULL, -- 状态检查约束 CONSTRAINT valid_status CHECK (status IN ('pending','paid','shipped','cancelled')) );

第五步：评估索引需求

• 必建索引：user_id（用户查订单）、created_at（按时间查）、status（查待发货订单）；
• 组合索引：(status, created_at)加速WHERE status='shipped' ORDER BY created_at DESC；
• 避免索引：items（JSON 字段，不建普通索引）。

第六步：估算存储与性能
按 1 亿订单计算：

• order_no VARCHAR(20)：平均 18 字符 × 1 亿 = 1.8GB；
• user_id BIGINT：8 字节 × 1 亿 = 0.8GB；
• items JSON：平均 500 字符 × 1 亿 = 5GB；
• total_amount DECIMAL(10,2)：5 字节 × 1 亿 = 0.5GB；
• 总计约 8.1GB，加上索引约 12GB。确认服务器磁盘充足。

第七步：编写初始化脚本并验证

-- 插入测试数据 INSERT INTO orders (order_no, user_id, items, total_amount, status, paid_at) VALUES ('ORD2024031500001', 1001, '{"items":[{"id":101,"qty":2,"price":99.99}]}', 199.98, 'paid', NOW()), ('ORD2024031500002', 1002, '{"items":[{"id":102,"qty":1,"price":299.99}]}', 299.99, 'pending', NULL); -- 验证查询 SELECT order_no, total_amount, status FROM orders WHERE user_id = 1001; -- 检查 JSON 提取 SELECT order_no, items->>'$.items[0].id' AS item_id FROM orders;

注意：MySQL 8.0+ 的JSON_EXTRACT(items, '$.items[0].id')语法更标准，但 PostgreSQL 用->>更简洁。跨库时，建议封装 DAO 层屏蔽差异。

3.2 跨数据库迁移实战：从 MySQL 到 PostgreSQL 的避坑清单

我们曾将一个 500GB 的 MySQL 电商库迁到 PostgreSQL，耗时 72 小时，其中 60 小时花在数据类型适配。以下是血泪总结的迁移 checklist：

1. 整数类型映射

• TINYINT→SMALLINT（MySQL 的TINYINT是 1 字节，PostgreSQLSMALLINT是 2 字节，但TINYINT无符号范围 0~255，SMALLINT有符号 -32768~32767，完全覆盖）；
• INT→INTEGER；
• BIGINT→BIGINT；
• AUTO_INCREMENT→SERIAL（SERIAL是INTEGER+SEQUENCE，需手动创建序列或用GENERATED ALWAYS AS IDENTITY（PG 10+））。

2. 字符串类型映射

• VARCHAR(n)→VARCHAR(n)（完全兼容）；
• TEXT→TEXT（兼容，但 PostgreSQLTEXT无长度限制，MySQLTEXT最大 64KB）；
• LONGTEXT→TEXT（PostgreSQLTEXT支持超大文本）；
• ENUM→VARCHAR(n)或自定义ENUM（PostgreSQL 支持CREATE TYPE status AS ENUM ('pending','paid');，但需提前创建）。

3. 日期时间类型映射

• DATETIME→TIMESTAMP WITHOUT TIME ZONE（若 MySQL 服务器时区固定，可忽略时区）；
• TIMESTAMP→TIMESTAMP WITH TIME ZONE（推荐，自动处理时区）；
• DATE→DATE（完全兼容）；
• TIME→TIME WITHOUT TIME ZONE（兼容）。

4. 布尔类型映射

• TINYINT(1)→BOOLEAN（PostgreSQL 原生BOOLEAN，0→false，1→true）；
• 迁移脚本需处理：UPDATE orders SET status = CASE WHEN status = 0 THEN 'false' ELSE 'true' END（先转字符串再转布尔）。

5. JSON 类型映射

• JSON→JSONB（PostgreSQL 的JSONB是二进制格式，查询更快，支持索引）；
• 迁移时用to_jsonb()函数：INSERT INTO pg_orders SELECT id, to_jsonb(items) FROM mysql_orders。

6. 索引与约束迁移

• MySQL 的FULLTEXT索引 → PostgreSQL 的GIN索引 +to_tsvector()；
• UNIQUE约束直接迁移；
• FOREIGN KEY需确保引用表已存在。

7. 验证脚本（必须执行）

-- 检查行数一致性 SELECT (SELECT COUNT(*) FROM mysql.orders) AS mysql_count, (SELECT COUNT(*) FROM pg.orders) AS pg_count; -- 检查金额精度（抽样 1000 行） SELECT o1.total_amount AS mysql_amt, o2.total_amount AS pg_amt FROM mysql.orders o1 JOIN pg.orders o2 ON o1.order_no = o2.order_no WHERE o1.total_amount != o2.total_amount LIMIT 10;

实操心得：迁移前用pt-table-checksum（Percona Toolkit）校验 MySQL 主从一致性；迁移中用pgloader工具自动处理类型转换，比手写mysqldump+sed替换可靠 10 倍；迁移后重点压测JOIN查询，PostgreSQL 的HASH JOIN和MERGE JOIN策略与 MySQL 不同，可能需调整work_mem参数。

3.3 性能调优实录：从慢查询到毫秒响应的四次迭代

一个订单搜索接口，初始 SQL：

SELECT * FROM orders WHERE status = 'shipped' AND created_at BETWEEN '2024-01-01' AND '2024-03-01' ORDER BY created_at DESC LIMIT 100;

线上平均 8.2 秒。我们分四步优化：

第一次：索引诊断（耗时 0.5 小时）
执行EXPLAIN ANALYZE：

Seq Scan on orders (cost=0.00..123456.78 rows=12345 width=200) (actual time=0.123..8200.456 rows=100 loops=1) Filter: ((status = 'shipped'::text) AND (created_at >= '2024-01-01 00:00:00'::timestamp without time zone) AND (created_at <= '2024-03-01 00:00:00'::timestamp without time zone)) Rows Removed by Filter: 999900

全表扫描！原因：status和created_at无组合索引。建索引：

CREATE INDEX idx_orders_status_created ON orders(status, created_at);

查询降至 1.3 秒。但EXPLAIN显示Index Scan using idx_orders_status_created，仍扫描 12 万行才找到 100 条。

第二次：覆盖索引（耗时 1 小时）
SELECT *需回表取所有字段，而索引只存status和created_at。建覆盖索引：

CREATE INDEX idx_orders_covering ON orders(status, created_at) INCLUDE (order_no, user_id, total_amount, paid_at);

（PostgreSQL 11+ 支持INCLUDE，MySQL 用联合索引INDEX(status, created_at, order_no, user_id, ...)）
查询降至 0.4 秒。EXPLAIN显示Index Only Scan，无需回表。

第三次：分区裁剪（耗时 3 小时）
订单表已达 2 亿行，created_at范围查询仍慢。按月分区：

-- PostgreSQL 分区表 CREATE TABLE orders_part (LIKE orders INCLUDING ALL) PARTITION BY RANGE (created_at); CREATE TABLE orders_202401 PARTITION OF orders_part FOR VALUES FROM ('2024-01-01') TO ('2024-02-01'); CREATE TABLE orders_202402 PARTITION OF orders_part FOR VALUES FROM ('2024-02-01') TO ('2024-03-01'); -- 重命名原表，交换数据 ALTER TABLE orders RENAME TO orders_old; ALTER TABLE orders_part RENAME TO orders;

查询降至 0.08 秒。EXPLAIN显示只扫描orders_202401和orders_202402两个分区。

第四次：物化视图预计算（耗时 2 小时）
业务要求实时查“各状态订单数”，SELECT status, COUNT(*) FROM orders GROUP BY status每次扫全表。建物化视图：

CREATE MATERIALIZED VIEW orders_status_count AS SELECT status, COUNT(*) as cnt FROM orders GROUP BY status; REFRESH MATERIALIZED VIEW CONCURRENTLY orders_status_count; -- 并发刷新，不锁表

查询SELECT * FROM orders_status_count降至 0.002 秒。
最终效果：接口 P99 从 8200ms 降至 12ms，服务器 CPU 使用率下降 35%。

关键经验：索引不是越多越好。我们曾为orders表建了 12 个索引，导致INSERT速度从 5000 QPS 降到 800 QPS。现在坚持“一个查询一个索引”，用pg_stat_statements监控慢查询，只对 QPS > 10 且耗时 > 100ms 的查询建索引。

4. 常见问题与排查技巧实录：生产环境踩坑大全

4.1 数据截断：为什么“Michael”变成了“Micha”？

这是新手最常犯的