MySQL 8.0 root连接失败因默认认证插件caching_sha2_password不兼容旧客户端，需改用mysql_native_password；订单表避免TIMESTAMP自动更新陷阱，created_at和updated_at应明确声明；查询慢优先优化联合索引，高并发扣减库存须确保sku_id有索引并用SELECT FOR UPDATE。
MySQL 8.0 安装后无法用 root 连接？默认认证插件是罪魁祸首
电商环境首次启动 MySQL 时，mysql -u root -p 报错 ERROR 1698 (28000): Access denied for user 'root'@'localhost'，不是密码错了，而是 MySQL 8.0 默认改用 caching_sha2_password 插件，而很多客户端（包括旧版 mysql-client、某些 PHP PDO 驱动）不兼容。
临时解决（开发/测试环境推荐）：
- 登录系统用户（非 mysql 用户），用
sudo mysqld_safe --skip-grant-tables &启动免鉴权服务 - 再开一个终端，执行
mysql -u root直连（此时无密码） - 运行：
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY 'your_secure_password';
- 重启 MySQL：
sudo systemctl restart mysql
生产环境建议保留 caching_sha2_password，但确保应用层使用支持该插件的驱动（如 MySQL Connector/J 8.0+、PyMySQL 0.10+）。
电商订单表设计必须避开 TIMESTAMP 自动更新陷阱
订单创建时间（created_at）和最后更新时间（updated_at）若都用 TIMESTAMP 类型，MySQL 5.6+ 默认会对第一个 TIMESTAMP 列加 ON UPDATE CURRENT_TIMESTAMP，导致插入订单时 updated_at 被意外覆盖为当前时间，掩盖真实业务更新动作。
正确做法：
-
created_at设为TIMESTAMP DEFAULT CURRENT_TIMESTAMP -
updated_at显式声明为TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP（仅此一列） - 或统一用
DATETIME+ 应用层写入（更可控，避免时区转换歧义） - 建表时禁用隐式行为：
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
订单状态变更必须靠应用逻辑触发 UPDATE ... SET status = ?, updated_at = NOW() WHERE order_id = ?，不能依赖 MySQL 自动更新。
订单查询慢？别急着加索引，先看 WHERE 条件是否走索引
电商常见慢查：按用户查订单列表（SELECT * FROM orders WHERE user_id = ? ORDER BY created_at DESC LIMIT 20），即使有 user_id 索引，如果 created_at 没参与索引，MySQL 仍需回表排序，数据量大时 I/O 暴涨。
优化方案：
- 建立联合索引：
ALTER TABLE orders ADD INDEX idx_user_created (user_id, created_at DESC); - 避免
SELECT *，只查必要字段（如id, order_no, status, amount），减少传输和内存开销 - 注意：MySQL 8.0+ 支持降序索引，但 5.7 只能升序存储，
ORDER BY created_at DESC在 5.7 下仍可能失效，需用ORDER BY created_at ASC+ 应用层反转 - 用
EXPLAIN FORMAT=TREE看执行计划，确认是否用了索引及是否出现Using filesort
高并发下单场景下，INSERT 性能比查询更重要，索引越多写越慢，订单表主键务必用自增 BIGINT，别用 UUID 或雪花 ID 做聚簇索引。
订单库存扣减必须用 SELECT FOR UPDATE，但别锁整张表
秒杀或高并发下单时，“查库存 → 判定是否充足 → 扣减”三步若不用事务+行锁，必然超卖。但直接 SELECT * FROM stock WHERE sku_id = ? FOR UPDATE 在未命中索引时会升级为表锁，拖垮整个库存模块。
关键保障点：
-
sku_id字段必须有唯一索引或主键，否则FOR UPDATE锁的是间隙（Gap Lock），范围过大 - 事务内操作要快：查完立刻 update，不要在事务里调外部 API 或做复杂计算
- 避免长事务：PHP 的
max_execution_time、Java 的@Transactional(timeout=3)必须设值 - 库存表建议单独拆分，与订单主表解耦，用最终一致性（如发 MQ 消息异步扣减）替代强一致，降低数据库压力
真正难的不是语法，是判断哪一行该被锁、锁多久、谁来释放——这些都得落在具体业务分支里，而不是堆配置。
