mysql 8.0支付系统必须配置innodb_flush_log_at_trx_commit=1、sync_binlog=1、transaction_isolation=’READ-COMMITTED’；建库须用utf8mb4_unicode_ci；核心表需乐观锁、联合索引及DECIMAL金额字段。
MySQL 8.0 安装后必须改的 3 个配置项
支付系统不能直接用默认 MySQL 配置跑，否则事务隔离、崩溃恢复、主从同步都可能出问题。最常被忽略的是 innodb_flush_log_at_trx_commit、sync_binlog 和 transaction_isolation 这三项。
生产环境必须设为：
-
innodb_flush_log_at_trx_commit = 1（确保每次事务提交都刷盘，避免宕机丢数据） -
sync_binlog = 1（binlog 同步写盘，主从一致性基础） -
transaction_isolation = 'READ-COMMITTED'（比默认的REPEAtable-READ更适合高并发支付场景，减少间隙锁冲突）
这些值写在 /etc/my.cnf 的 [mysqld] 段下，改完要重启 MySQL，不是 reload 就生效。
建库时必须指定的字符集与排序规则
支付系统涉及多币种、多语言商户名、证件号、备注字段，utf8mb4 是底线，但只设 CHARACTER SET utf8mb4 不够，排序规则选错会导致索引失效或 WHERE 查询不命中。
建库语句必须显式声明：
CREATE DATABASE payment_db CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;注意：utf8mb4_bin 虽然区分大小写且性能略高，但会破坏手机号、订单号等业务字段的常规比较逻辑；utf8mb4_unicode_ci 支持更合理的 Unicode 排序，兼容性更好。
后续所有表创建也需继承该库默认规则，不要在 CREATE TABLE 中重复指定，除非有特殊字段需要 _bin 对比。
支付核心表必须加的事务级约束与索引
比如订单表 payment_order，光有主键和唯一索引不够，容易在并发扣款时出现超卖或重复支付。
关键设计点：
- 用
status字段 +version（乐观锁）组合更新，避免select ... for UPDATE在高并发下成为瓶颈 - 必须为
(out_trade_no, status)建联合索引——查回调、查状态时高频使用，且能覆盖查询减少回表 - 禁止在
WHERE条件中对amount字段做函数操作，例如WHERE ROUND(amount, 2) = 100.00，会导致索引失效 - 所有金额字段统一用
DECIMAL(16,2)，不用Float或double，避免浮点计算误差
建表后立即执行 SHOW CREATE TABLE payment_orderG，确认索引类型是 BTREE、无冗余索引、无隐式类型转换警告。
事务安全测试：如何验证配置真生效了
改完配置、建完库表，不能只靠“看起来没问题”。得用真实 SQL 流程验证事务行为是否符合预期。
一个最小闭环验证方法：
- 开两个 MySQL 客户端连接，都执行
SET TRANSACTION ISOLATION LEVEL READ COMMITTED; - A 连接插入一条未支付订单：
INSERT INTO payment_order (out_trade_no, status) VALUES ('test_001', 'INIT');，不提交 - B 连接执行
SELECT * FROM payment_order WHERE out_trade_no = 'test_001';→ 应该查不到 - A 提交，B 再查 → 应立刻看到新记录，且
status是'INIT' - 再用
SELECT @@innodb_flush_log_at_trx_commit;和SELECT @@sync_binlog;确认值确实是1
最容易被绕过的坑是：docker 启动 MySQL 时挂载了自定义 my.cnf，但容器内实际加载的是 /etc/mysql/mysql.conf.d/mysqld.cnf，导致配置没生效。务必进容器执行 mysql --help | grep "default options" 查真正读取路径。