ERP 开发必备：MySQL 表设计、事务锁与索引优化实战

做过ERP定制开发的朋友心里都有数：大部分业务系统从订单、采购、库存到财务凭证，最后都落在几张核心表上。MySQL 在江湖上被叫做“最流行的开源数据库”一点不夸张，中小型 ERP、进销存、生产管理、客户关系系统，几乎清一色拿它当底库。我这些年经手过不少工程类项目，反复被问到的问题也高度集中：MySQL 怎么装、怎么增删改查、事务怎么开、锁是怎么回事、存储过程怎么用、连接池怎么配。这篇就按 ERP 开发的真实使用顺序，把基础到落地的关键点捋一遍，不追求教科书式的全覆盖，但保证每一条都来自实际项目里踩过的坑和验证过的做法。适合刚转 ERP 开发的初中级工程师，也适合那些已经在用 MySQL、但很多细节只懂皮毛的伙伴。

1. 为什么 ERP 项目必须先把 MySQL 底层设计做对，而不是急着建表

1.1 ERP 数据模型和普通网站的根本差异

很多从 Web 开发转 ERP 的人，最不适应的就是数据设计思路。做内容型网站时，表结构相对自由，用户表、文章表、评论表之间即使不建物理外键，靠代码层关联也能跑。ERP 不一样，它管的是企业的钱、货、单据，一套单据从下单、审核、发货、收货、对账到生成凭证，中间任何一环的数据错了，后果都直接反映在财务账上。

所以在 MySQL 里做 ERP，第一步不是急着手写 CREATE TABLE，而是先回答几个问题：这个业务实体的主键怎么定？哪些字段必须唯一？哪些字段不允许为空？哪些数据在做删除时要保留历史痕迹而不是物理删除？这些问题落到底层，就是 MySQL 的主键约束、唯一索引、非空约束、逻辑删除字段。举个例子，采购订单和采购订单明细就是典型的一对多关系，订单主表记录单头信息，明细表记录物料、数量、单价、金额。如果明细表里没有外键指向主表，插入一个没有单头的明细，业务数据立刻就脏了。MySQL 的外键约束虽然很多人嫌它影响性能，但在 ERP 这种严格要求数据完整性的系统里，该用还是得用。

字段设计上还有一类高频错误：把金额字段用 FLOAT 或 DOUBLE 存。浮点数在计算机里本来就是近似值，10.1 加 20.2 可能得到 30.299999...，短期看着没事，一到财务汇总就莫名其妙差几分钱。ERP 的金额字段一律用 DECIMAL，比如 DECIMAL(18,4)，前面是总位数，后面是小数位，按实际币种精度来定。日期时间字段同样要慎重，业务日期、单据日期、审核时间、修改时间各司其职，不要全用一个 DATETIME 糊弄。

1.2 引擎与字符集选型：InnoDB 和 utf8mb4 是默认答案

MySQL 5.5 之后默认引擎就是 InnoDB，到了 5.7 和 8.0 时代，ERP 项目根本没有纠结引擎的必要，直接 InnoDB。原因很明确：InnoDB 支持事务、支持行级锁、支持外键，崩溃恢复能力也可靠。MyISAM 虽然查询快一点，但它是表级锁，写并发一上来整张表卡死，更重要的是它不支持事务，一张订单明细写一半断电了，数据没法回滚，这在 ERP 场景里是不可接受的。

字符集这块我吃过亏。早年接手一个老项目，库表用的是 utf8，存中文表面上没问题，但一旦用户输入了 emoji 表情，或者某些生僻字，就会报“Incorrect string value”错误，甚至直接把数据截断。原因是 MySQL 的 utf8 最多只支持 3 字节字符，而 emoji 类和部分生僻字需要用 4 字节编码。现在统一用 utf8mb4，建库时指定默认字符集，表不用单独声明也能继承。排序规则一般用 utf8mb4_unicode_ci，它对各种语言的排序支持比 general_ci 更准确，代价是性能略低一点，在 ERP 这种查询量级下根本感知不到。

还有一个容易忽略的点：库、表、连接三个层面的字符集必须一致，否则即使表建对了，客户端连接用的还是 latin1，照样乱码。后面讲安装配置时会再说怎么一劳永逸地改掉默认连接字符集。

1.3 冗余字段与规范化之间的平衡

ERP 设计里经常听到“这张表要不要冗余一个字段”。教科书强调第三范式，减少数据冗余，但在实际 ERP 里，适度的冗余反而能简化查询、提升性能。例如订单明细表冗余物料名称，就不需要每次报表都去 JOIN 物料基础表；库存表冗余物料单位，查询时也更方便。关键是冗余字段要由程序或触发器保证同步，而不是靠手动维护。我曾经见过一个项目，物料名称在基础表和订单表里有三种叫法，月底对账对不上，最后查出来就是冗余不同步造成的。所以原则是：报表查询的稳定性和性能优先，但冗余必须在一个明确的数据入口统一更新。

2. 从增删改查到复杂查询：ERP 开发天天用的 SQL 实操

2.1 增删改查的正确写法与隐藏陷阱

CRUD 谁都会写，但 ERP 里的 CRUD 有很多细节决定系统能不能扛住业务量。先看 INSERT，一次插入一条还是批量插入，性能差距很大。向订单明细表插入五十条记录，循环执行五十次 INSERT，比拼成一条多值 INSERT 慢的可不是一点半点。MySQL 对单条 INSERT 语句的优化有限，每一条都是一次完整的事务边界，虽然自动提交模式下每条也是独立事务，但 SQL 解析、网络往返、日志刷盘的开销全都重复了。批量写法的价值在导入场景特别明显，比如 Excel 导入物料清单，几千行数据如果逐条插入，可能要几分钟；改成一次五百行批量插入，几十秒就能完成。

UPDATE 的关键是 WHERE 条件绝不能漏。ERP 里最怕的是“全表更新事故”：误执行了没有 WHERE 的 UPDATE，整张表价格或数量被统一覆盖，没有备份就只能干瞪眼。我的习惯是，任何 UPDATE 和 DELETE 语句先写 SELECT 验证结果集，确认影响行数正确后再改写成更新或删除。这个习惯救过我很多次。

DELETE 在 ERP 里更要谨慎，强业务数据永远不建议物理删除。订单、凭证、出入库记录，一旦删除可能破坏后续关联数据的完整性。实操上一般加一个 deleted 字段，查询时统一过滤 deleted = 0。这样做的另一个好处是支持误删恢复，真出了问题，把 deleted 改回来就行，不用跟 DBA 扯皮找备份。

2.2 排序、分页与聚合：订单列表和报表的日常

排序需求在 ERP 列表页里是最常见的。ORDER BY 的写法看似简单，坑也不少。中文排序默认按 Unicode 编码排，不是按拼音或者笔画排。想让物料名称按拼音排序，需要指定排序规则或者用 CONVERT 函数转换编码。另外，多字段排序时要注意顺序：ORDER BY date DESC, id DESC，是先按日期排，再在相同日期内按 id 排。不少新手把顺序写反了，结果同一天的单据顺序乱跳。

分页查询用 LIMIT 和 OFFSET。数据量小的时候无所谓，但 ERP 里明细数据很容易膨胀到百万级。LIMIT 100000, 20 这种写法，MySQL 会先取出前十万条再丢弃，页数越深越慢。实际项目里一般用“最大 ID 游标”代替跳页：WHERE id > 上一页最大id ORDER BY id LIMIT 20。当然这种写法会牺牲跳页功能，业务上如果必须跳页，就得上合适的索引或使用覆盖索引优化，或者接受深分页的延迟。

聚合查询是报表的核心，SUM、COUNT、GROUP BY、HAVING 是主力。举个例子，要统计每个客户的本月销售总额，SQL 大概是：

SELECT customer_id, SUM(order_amount) AS total_amount, COUNT(*) AS order_count FROM sales_order WHERE order_date >= '2025-01-01' AND order_date < '2025-02-01' GROUP BY customer_id HAVING total_amount > 10000 ORDER BY total_amount DESC

注意 WHERE 和 HAVING 的区别：WHERE 在分组前过滤原始行，HAVING 在分组后过滤聚合结果。很多人把“销售额大于一万的客户”这个条件写进 WHERE，就会漏掉那些汇总后达标、但单笔订单不满一万的记录。另外，COUNT(*) 和 COUNT(字段) 也有区别，前者统计所有行，后者不统计 NULL 值，遇到可空字段时会“莫名其妙少几条”，ERP 报表对不上就常源于这种细节。

2.3 多表连接与子查询：核心报表怎么拼

ERP 报表几乎没有单表查询，基本都是主表、明细表、基础资料表连起来。假设要导出一份带客户名称、物料名称的销售明细，典型写法：

SELECT o.order_no, c.customer_name, d.material_code, m.material_name, d.quantity, d.price, d.amount FROM sales_order o JOIN sales_order_detail d ON o.id = d.order_id JOIN customer c ON o.customer_id = c.id JOIN material m ON d.material_id = m.id WHERE o.order_date >= '2025-01-01'

JOIN 的类型要按业务选择。INNER JOIN 只返回两边都匹配的记录，比如订单明细对应的物料已经被删除，明细行就会从结果里消失，这种“消失”对报表可能是有问题的。LEFT JOIN 保留左表全部记录，右表没匹配上的字段显示 NULL，用于查“哪些订单没有明细”这类问题非常合适。RIGHT JOIN 在 MySQL 里存在但用得少，绝大多数场景用 LEFT JOIN 反转表的顺序就能实现，日常开发里写 RIGHT JOIN 反而让阅读者困惑。

子查询在 ERP 里主要用于两类场景：一类是查“在集合中”的数据，用 IN；另一类是查“不存在关联记录”的数据，用 NOT EXISTS。比如找出一个月内没有任何采购记录的供应商：

SELECT supplier_name FROM supplier s WHERE NOT EXISTS ( SELECT 1 FROM purchase_order p WHERE p.supplier_id = s.id AND p.order_date >= '2025-01-01' AND p.order_date < '2025-02-01' )

这里用 NOT EXISTS 比 NOT IN 更安全，因为 IN 子查询如果结果集中出现 NULL，整个 NOT IN 会返回空。这是 MySQL 里一个非常隐蔽的坑，我见过不止一次线上报表因为这个少了一堆数据。

3. 事务与并发锁：让库存不卖超、账不记乱的底层防线

3.1 ACID 在 ERP 场景里的实际映射

说到事务，网上各种理论一堆，落到 ERP 里其实就一句话：一组操作要么全部成功，要么全部失败，不能出现只做一半的状态。典型场景是销售出库：扣减库存、生成销售出库单、写客户应收账，这三步必须在一个事务里。如果库存扣了，但出库单因为字段校验失败没生成，整个事务回滚，库存还原，系统才不会出现账实不符。

MySQL 默认开启自动提交，每一条 SQL 都是一个独立事务。在 ERP 业务代码里，要手动控制事务边界，常规写法是：

START TRANSACTION; UPDATE inventory SET quantity = quantity - 5 WHERE material_id = 1001 AND warehouse_id = 2; INSERT INTO stock_out_log (material_id, warehouse_id, quantity, out_time) VALUES (1001, 2, 5, NOW()); COMMIT;

如果第二步插入失败，程序捕获异常后执行 ROLLBACK，库存不会被扣掉。这里有个很重要的细节：扣减库存的 UPDATE 语句，最好把“库存够不够”的判断直接写进 WHERE 条件，比如：

UPDATE inventory SET quantity = quantity - 5 WHERE material_id = 1001 AND warehouse_id = 2 AND quantity >= 5;

然后检查影响行数，如果影响行数为 0，说明库存不足，直接回滚。这种写法比先 SELECT 判断、再 UPDATE 的方式要稳得多，因为它把“判断和更新”合并成一个原子操作，天然避免并发卖超。先查后改在并发场景下会出大问题：A 事务查到库存还有 5 件，B 事务也查到还有 5 件，然后 A 扣掉 5，B 再扣掉 5，库存变成负数，超卖事故就发生了。

3.2 隔离级别与 ERP 业务场景的对应关系

事务隔离级别决定了并发事务之间能看到彼此多少未提交或已提交的数据。MySQL InnoDB 默认是可重复读（REPEATABLE READ），Oracle 默认是读已提交（READ COMMITTED），两个默认值背后有各自的场景考量。

表格列一下四种隔离级别和对应问题：

ERP 系统里很难只用一个隔离级别。普通报表查询用默认可重复读没问题，但到了高并发扣库存、抢单据号这种场景，可重复读配合间隙锁会出现意外的锁范围扩大。有些项目把关键写事务的会话隔离级别临时降到读已提交，换取更小的锁范围、更高并发，这也是很多大厂的通用做法。

实际调整示例：

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED; START TRANSACTION; ...需要高并发的更新逻辑... COMMIT;

隔离级别不是越高越好，SERIALIZABLE 基本上是把并发变成串行，ERP 系统如果所有写操作都串行，一天的单据都录不完。选什么级别要跟具体业务场景对应：并发高、一致性要求相对宽松的读多写少场景，可以降级；资金账、库存账的强快照查询，保持默认就不错。

3.3 锁的分类与实际排查

MySQL 锁是 ERP 并发问题里的重头戏，面试爱考，线上排查更绕不开。按粒度分，锁分为表级锁和行级锁。MyISAM 只有表锁，InnoDB 支持行锁。按类型分，主要有共享锁（S）和排他锁（X）。共享锁之间兼容，共享锁和排他锁互斥，排他锁之间也互斥。普通 SELECT 不加锁，走的是 MVCC 快照读；SELECT ... FOR UPDATE 和 UPDATE、DELETE 才会加排他锁。

InnoDB 还有意向锁，作用是表级别上声明“我要在某行加锁”。事务要加行锁前，先加意向锁，这样其他事务想对整张表加锁时，不用逐行扫描就知道表里有行被锁住。中间还有间隙锁和临键锁。间隙锁锁的是记录之间的间隙，防止其他事务在这个间隙里插入新记录。在可重复读隔离级别下，InnoDB 会用临键锁把“已锁定的行和它前后的间隙”一起锁住，这就是为什么明明只更新一条记录，却可能阻塞了范围内的插入操作。

死锁是 ERP 开发最头痛的问题之一。死锁的典型形成条件是：两个事务各持有一把锁，同时等待对方的锁。举例，事务 A 先更新了物料表，再更新仓库表；事务 B 先更新仓库表，再更新物料表。这样两边互等，MySQL 的死锁检测机制会牺牲掉其中一个事务，让它回滚，另一个继续执行。应用程序不需要处理死锁本身，但要做好异常捕获，捕获到死锁错误后重试整个事务。

排查死锁和锁等待，我最常用的命令是：

SHOW ENGINE INNODB STATUS;

这个命令会输出一大段状态信息，重点看“LATEST DETECTED DEADLOCK”这一段，里面记录了死锁双方执行的 SQL、锁住的索引等。还有一张信息表也能查事务和锁状态：

SELECT * FROM information_schema.INNODB_TRX; SELECT * FROM information_schema.INNODB_WAITS;

日常预防死锁，经验上有几条非常管用：所有并发事务访问多张表时，统一按相同顺序操作；UPDATE 尽量走唯一索引，缩小锁范围；尽量把事务做小做短，减少锁持有时间；对于高并发扣减类操作，考虑用单行更新加条件判断代替复杂的先查后写。

4. 安装配置、表结构改造与连接池：项目落地阶段的高频操作

4.1 Windows 和 Linux 下的安装差异

很多新手在 Windows 10 上装 MySQL，最顺的方法是下载 ZIP 免安装版而不是用图形安装包。解压后在目录下创建 my.ini，配置 basedir、datadir、port 和 character-set-server，然后以管理员身份打开命令行，依次执行初始化、安装服务和启动服务。初始化命令有两个版本，5.7 用 mysqld --initialize-insecure，它会生成一个空密码的 root 用户并创建数据目录，8.0 也一样，只是后续设置密码的命令语法变了：

ALTER USER 'root'@'localhost' IDENTIFIED BY 'NewPass123!';

如果是用系统内置包管理器安装 MySQL，拿 RPM 系发行版举例，通常要按顺序安装 mysql-community-common、libs、client、server 这些 RPM 包，依赖关系没理清就会卡在第一步。装完还要手动启动 mysqld 服务，查看初始化日志里生成的临时密码，首次登录后必须改密码。社区版从 5.7 到 8.0，安装逻辑基本一致，但 8.0 的默认认证插件改成了 caching_sha2_password，老客户端连不上时要在创建用户时指定 mysql_native_password，或者升级客户端驱动。

Docker 安装 MySQL 也很常见，但踩坑率不低。最常见的原因是容器端口映射配置不对，或者在启动命令里没设置 root 密码环境变量，导致容器启动后瞬间退出。一个能稳定跑起来的示例：

docker run -d \ --name mysql-8 \ -p 3306:3306 \ -e MYSQL_ROOT_PASSWORD=root123 \ -v /opt/mysql-data:/var/lib/mysql \ mysql:8.0

还有个隐蔽问题：宿主机数据目录权限不对，MySQL 容器以 mysql 用户运行，但挂载的宿主机目录是 root 所有，容器初始化就失败。解决办法是给目录授权，或者用命名卷让 Docker 自动管理。启动失败第一件事永远是 docker logs 容器名，看具体报错信息，而不是反复重启。

4.2 修改表结构的正确姿势：DDL 的坑远比想象的多

ERP 项目上线后表结构几乎一定会改。比如物料表要新增一个“是否启用批次管理”字段、订单表要把某个字段默认值从 0 改成 1，对应的就是 ALTER TABLE。相关热词里总有人搜“mysql 数据库修改结构”“mysql 设置默认值为0”，说明这块需求确实高频。

标准操作：

ALTER TABLE material ADD COLUMN batch_management TINYINT NOT NULL DEFAULT 0 COMMENT '是否启用批次管理'; ALTER TABLE material MODIFY COLUMN batch_management TINYINT NOT NULL DEFAULT 1 COMMENT '是否启用批次管理';

但 ALTER TABLE 不是随便执行的。在 MySQL 5.7 之前，很多 DDL 操作要复制全表数据，在数据量大的表上执行一次要锁表几个小时，业务直接停摆。5.7 和 8.0 支持了一部分在线 DDL，但依然会占用元数据锁。所谓元数据锁，是任何 DDL 操作开始时，系统会防止其他会话在这张表上做读写。如果表上有长期未提交的事务，DDL 会一直等待元数据锁，表现就是 ALTER 语句卡住。这种情况一般建议在上线窗口执行，先查一下有没有长事务：

SELECT * FROM information_schema.INNODB_TRX;

把长时间运行的写事务处理完再执行 DDL，成功率会高很多。另外 8.0 里 MODIFY 和 CHANGE 的语法细节要区分清楚，MODIFY 改字段定义，CHANGE 可以同时改字段名和定义，别在 CHANGE 里漏掉新字段名导致误改。

4.3 连接池配置：性能瓶颈往往不在数据库

ERP 应用连接数据库，强烈建议使用连接池而不是每次操作都新建连接。常见的 Java 生态里有 HikariCP、Druid，Python 生态有 SQLAlchemy 连接池。连接池的核心意义是复用连接，避免每次请求都经历 TCP 握手、认证、关闭的完整流程。新建一次 MySQL 连接大概是毫秒级到几十毫秒级，在高频后台操作下累加起来非常可观。

HikariCP 的典型配置经验是：maximumPoolSize 别设太大。很多人以为连接数越多越快，实际上每个连接在数据库端都有资源开销，连接数过多会导致线程切换加剧、锁等待反而变长。对于中小型 ERP，物理连接几十个足够，瓶颈往往在 SQL 本身。还要注意连接的有效检测，MySQL 有个 wait_timeout 参数，连接空闲超过这个时间就会被服务端断开。连接池如果不检查连接可用性，用到一半发现连接已经断了，就会报“Connection is not available”之类的错误。连接池配置里一般有个最小空闲连接数，或者 setConnectionTestQuery，目的就是定期验证连接是否还活着。

给 ERP 系统做连接层优化，还应关注数据库端的 max_connections，默认值可能只有 151，如果应用部署了多个实例，每个实例的池子默认几十个连接，超过这个上限，新连接直接报“Too many connections”。要么调大 max_connections，要么合理收敛各应用实例的连接池大小。

4.4 账号权限与常见连接报错

权限管理在 ERP 里的作用容易被低估。开发环境和生产环境的账号必须分开，生产账号按最小权限原则，只给 SELECT、INSERT、UPDATE、DELETE 权限，不要把 GRANT、ALTER 权限给到应用账号。创建账号并授权的示例：

CREATE USER 'erp_app'@'%' IDENTIFIED BY 'Passw0rd!'; GRANT SELECT, INSERT, UPDATE, DELETE ON erp_db.* TO 'erp_app'@'%';

如果应用连接时收到“Access denied”，要分两种原因排查：一是密码错误，二是账号的 host 限制不匹配。客户端 IP 不在授权 host 范围内同样会被拒绝。另一种常见报错是“SSL connection error”，MySQL 8.0 默认要求连接使用 SSL，旧客户端或特定驱动版本不兼容时，可以在连接参数里显式关闭 SSL，或者在创建用户时指定 REQUIRE NONE。需要注意，关闭 SSL 会降低传输安全性，内网开发环境为了调试方便可以这样处理，生产环境建议还是把 SSL 配好。

数据迁移和备份方面，最常用的还是 mysqldump 和 mysqlpump。ERP 系统做增量或者全量备份，mysqldump 配合 binlog 就能完成基本方案。日常开发里同步数据库结构、把 Excel 数据导入表，也都有对应的命令行工具和开发库，Excel 数据量大时先导出成 CSV，再用 LOAD DATA INFILE 导入，比逐行 INSERT 快几个数量级。

5. 存储过程、函数和索引：哪些该自动化，哪些别过度封装

5.1 存储过程在 ERP 里的典型用途与注意点

存储过程这几年存在感不如以前，因为很多业务逻辑被挪到了应用层，用 Java、Python 写更便于维护和测试。但 ERP 里有些固定逻辑仍然适合放在数据库里。典型的是单据编号生成，比如销售订单号要按“年份+月份+流水号”生成，并且要保证高并发下不重号。把生成逻辑写成一个存储过程或函数，应用层只需要调用一次，编号的原子性由数据库保证。

另一个典型用途是月末关账和库存结转。这类操作涉及大量表的批量更新，嵌套事务非常多，放在存储过程里可以把一整串更新步骤合并成一个提交点，中途出错整体回滚。逻辑完整、出入参数清晰，DBA 也方便做性能优化。

但存储过程也有明显缺点：难以调试、版本控制困难、对开发团队能力要求高。经常有人把大量业务逻辑全塞进一个几百行的存储过程，出了 bug 改起来费劲，而且存储过程的优化很依赖对执行计划的理解。我的建议是：高频、原子、无跨系统协作的数据库逻辑用存储过程没问题，复杂到需要调用外部接口、需要灵活扩展的业务规则，还是放在应用层更稳妥。

简单示例，一个根据物料 ID 查询当前库存的函数：

DELIMITER $$ CREATE FUNCTION get_stock(material_id_param INT) RETURNS DECIMAL(18,4) DETERMINISTIC BEGIN DECLARE stock_qty DECIMAL(18,4); SELECT quantity INTO stock_qty FROM inventory WHERE material_id = material_id_param; RETURN stock_qty; END$$ DELIMITER ;

调用直接 SELECT get_stock(1001) 即可。这种封装在处理报表里重复出现的计算逻辑时很省事，但要小心函数内部依赖当前会话状态，以及函数内大量查询引发性能问题。

5.2 触发器：能不用就尽量别用

触发器和存储过程不太一样，它是在表的 INSERT、UPDATE、DELETE 操作前后自动执行的一段逻辑。很多 ERP 初学者喜欢用触发器同步库存：出库明细插入后，触发器自动更新库存表。听起来很爽，实际坑非常多。触发器对开发者是隐形的，排查线上数据问题时，你不知道那段数据变化是被哪段隐藏代码修改的，光这一点就足够劝退了。

另外一个实际问题，触发器会让单条 INSERT 的耗时显著变大，因为每次操作都要额外执行一段逻辑。高并发写入下，触发器的开销会被放大。另外，触发器中如果出现异常，会直接回滚主操作。我曾经维护过一个项目，客户资料表上有个触发器，逻辑里有一行有问题的 UPDATE，导致正常的客户新增都失败，花了很长时间才定位到。

所以我对触发器的态度非常鲜明：数据同步、复杂计算、跨表一致性维护，都不要依赖触发器。可以用显式事务、应用层代码或者事件调度器去处理。实在要用，也只做最简单的“写审计日志”这种无副作用的操作，并且一定要在表结构变更时重新审查。

5.3 索引设计：让 ERP 报表和列表不再慢

索引是所有数据库优化里投入产出比最高的一项。ERP 系统最常见的慢查询，就是 WHERE 条件用了非索引字段，或者索引没有按最左前缀原则使用。设计索引前，先搞清楚这张表最频繁的查询路径是什么。比如销售订单明细表，每天按“订单日期+客户 ID”查，那就建一个联合索引 (order_date, customer_id)。但是要注意，联合索引的字段顺序极其重要，MySQL 只能从最左字段开始使用索引。索引是 (order_date, customer_id)，查询条件只有 customer_id 时，索引是用不上的；查询条件只有 order_date 时，索引能用——这就是最左前缀原则。

索引也不是越多越好。每个索引在写操作时都要同步维护，索引太多，INSERT、UPDATE 的性能反而下降。一个折中的做法是，把重复的和冗余的索引清理掉，比如已经有 (a, b) 联合索引，就没必要再单独建一个 a 索引，因为联合索引已经包含了 a 的前缀段。

排查慢 SQL，打开慢查询日志是第一步：

SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 1;

超过 1 秒的查询会记录到日志里。拿到慢 SQL 后用 EXPLAIN 分析执行计划，重点看 type 列、key 列、rows 列。type 从好到差大致是 const、eq_ref、ref、range、index、ALL，如果看到 ALL，就是全表扫描，几乎必然要加索引优化。

6. 常见报错与排查实录：真实项目里遇到的几个典型问题

6.1 长事务与表结构变更互相卡死

有一次我执行ALTER TABLE，怎么都完成不了，客户端一直转圈。先用 INNODB_TRX 查，发现有一条事务已经运行了好几个小时，一直在更新同一个大表。这个长事务不提交，ALTER 就拿不到元数据锁，两边僵持。处理方案是跟业务方确认长事务是否可以杀掉，KILL 掉那个线程后，ALTER 马上执行完成。这个经验说明：任何时候做 DDL，先检查长时间未结束的事务，真是能省掉好几个小时的排查时间。

6.2 “Too many connections”到底怎么回事

一个 ERP 项目上线后突然所有应用都提示 Too many connections，我第一反应是 max_connections 不够。登录数据库查看，确实默认值才 151，而生产环境部署了四个应用实例，每个实例连接池 30 个连接，稍一繁忙就超过 151。调高 max_connections 的同时，我检查了应用连接池，发现有几个连接一直没释放，原因是应用层异常后没有正确归还连接。两件事同时处理，问题才算真正解决。这类故障单纯调数据库参数是治标不治本，连接泄漏还是会在未来重新爆掉。排查连接占用情况，可以看 PROCESSLIST：

SHOW FULL PROCESSLIST;

如果发现大量 Sleep 状态的连接长时间不清，就要回头检查连接池配置和应用代码。

6.3 版本选择的一个小建议

MySQL 5.7 系列更新到了 5.7.44，之后官方不再推出新的 5.7 小版本，社区里关于“5.7.44 和 5.7.43 有什么区别”的讨论也很多。对于 ERP 项目，如果新搭建系统，我更推荐使用 8.0 的稳定版本，比如 8.0.4x 的 LTS 版本，它的性能、默认字符集、窗口函数等能力都比 5.7 好不少。存量 5.7 系统如果没有特殊兼容需求，也建议规划升级。不过升级不是简单替换二进制文件，要做兼容性测试，尤其是应用层驱动的版本、视图、存储过程里的写法，8.0 对部分语法的要求更严格。

我自己在升级时踩过一个坑：8.0 默认字符集和排序规则是 utf8mb4_0900_ai_ci，老库里表用的是 utf8_general_ci，导入数据后有个别字段排序结果跟原来不一样，报表里的地区清单顺序整个变了。建议升级前把所有表和字段的字符集统一规划好，避免这种隐性现象。

6.4 排查问题要建一个属于自己的工具集

做 ERP 开发，数据库管理工具几乎是必需品。我自己长年用一个叫 DBx 的数据库管理客户端，日常的表结构查看、SQL 编辑、数据导出都用它，效率比在命令行里敲高不少。命令行虽然万能，但图形工具对表结构变更、索引查看、数据对比这类操作更直观。此外，常用的还有 mysqldump 做逻辑备份、二进制日志工具做增量分析，以及连接 C++、Python 等不同语言的 MySQL 驱动。做接口集成时，有人用 C++ 连 MySQL，配置好 mysqlclient 库后执行查询，核心也就是初始化、执行、取结果、清理这几步，掌握基础 API 后很快能上手。

工具不在多，关键是每个项目的团队要统一。有人用 A 工具、有人用 B 工具，导出的 Excel 格式、SQL 注释风格不一致，协作起来很别扭。至少导出的文件要能被 LOAD DATA 或者数据库同步软件直接消费，减少手工清洗环节。

做 ERP 开发这几年，我最大的体会是：MySQL 本身不难，难的是把业务规则翻译成正确、稳定、扛得住并发的 SQL 和表结构。以上这些内容，都是我从订单、库存、财务、生产等真实项目里反复打磨出来的经验。如果你正在搭一个 ERP 或者正在排查一个说不清原因的数据问题，建议先回到数据库层面看一遍：表设计是不是合理、事务边界是不是清晰、锁冲突是不是被忽略、索引是不是匹配查询路径。这些东西想清楚了，绝大多数业务层的疑难杂症都能迎刃而解。