技术博客
MySQL 报错 ERROR 1146 (42S02): Table ‘db_name.table_name’ doesn’t exist 最常见的原因是大小写或拼写错误。Linux 系统下 MySQL 默认区分表名大小写（由 lower_case_table_names 系统变量控制），而 Windows 不区分。如果你在开发机（Windows）建的表叫 User，部署到 Linux 服务器时执行 SELECT * FROM user 就可能报 1146。
MySQL 主从延迟不是靠 SHOW SLAVE STATUS 里 Seconds_Behind_Master 一眼就能信的。这个值在从库 IO 线程没拉到最新 binlog、SQL 线程卡住、甚至主库时钟漂移时都会失真。更可靠的方式是用 GTID 或时间戳打点：
直接执行 SELECT VERSION(); 是最可靠的方式，它返回服务器实际运行的完整版本字符串（如 8.0.33 或 5.7.44）。不要依赖 mysql –version 或包管理器查到的客户端版本，它们和服务器版本可能不一致。
迁移前必须核对 mysqld –version 输出的版本号，尤其是小版本（如 8.0.33 vs 8.0.37），部分 MySQL Group Replication 或 InnoDB Cluster 要求最低版本为 8.0.19，而 Percona XtraDB Cluster 对 5.7 支持已逐步终止。若单机是 5.6 或更早，不能直连 MGR 或 PXC，需先升级到 5.7.25+ 或 8.0.19+ 并完成 mysql_upgrade。
企业内部常有部门调整、汇报关系变更、岗位轮换，employee 表不能只存静态信息。必须包含 manager_id（自关联到本表 id）、department_id（外键到独立 department 表）、status（如 ‘active’/’on_leave’/’archived’），避免用字符串存部门名或上级姓名。
MySQL 主从复制依赖于主库的二进制日志（binlog），如果没开，从库根本收不到任何变更。先登录主库执行：
你启动MySQL服务时执行 sudo service mysql start，真正被拉起来的，是一个名叫 mysqld 的后台进程——这个进程及其占用的内存、线程、日志缓冲区、查询缓存、连接管理器等合在一起，就叫“MySQL实例”。它不存数据，但管着所有数据库文件的读写、权限校验、SQL解析和事务调度。你连不上数据库？大概率是这个实例没在跑，而不是某个库丢了。
MySQL报错不用慌，关键不是重写SQL，而是用四层线索快速锁死问题位置：错误码→语句结构→对象状态→权限日志。
直接查 INFORMATION_SCHEMA.COLUMNS 是最可靠的方式，它不依赖客户端工具或表结构缓存，返回的是服务端真实元数据。
MySQL 死锁无法通过调大 innodb_lock_wait_timeout 或关掉自动提交来“避免”，它本质是多个事务以不同顺序加锁同一组资源（比如两行记录、两个索引项）导致的循环等待。预防的核心是让所有事务按**相同顺序**访问资源。