技术博客
不能直接用 composer create-project 安装 laravel-admin，它不是独立项目，而是 Laravel 的扩展包。 你得先有 Laravel 应用，再通过 composer require 引入它——否则会报错 laravel-admin requires laravel/framework ^10.0（或对应版本）这类依赖冲突，根本走不下去。
因为 MySQL 实际执行时，会先扫描 offset + count 行数据，再丢弃前 offset 行——哪怕你只要 1 条，它也可能扫了 800 万行。
JSON_TABLE 是 MySQL 8.0.4+ 提供的函数，核心作用是把一行 JSON 字符串「展开」成多行关系表。它不处理嵌套太深的结构，也不适合做 JSON 校验或提取单个字段——那是 JSON_EXTRACT 或 -> 操作符的事。
InnoDB 通过多版本并发控制（MVCC）、undo log、redo log、锁机制和两阶段提交（2PC）协同实现事务的 ACID 特性。它不是靠单一组件，而是多个模块紧密配合：undo log 保证回滚与一致性读，redo log 确保持久性，行级锁+意向锁支撑隔离性，而事务状态管理和崩溃恢复逻辑则由事务子系统统一协调。
直接说结论：100GB 数据可能 2 小时迁完，也可能拖 3 天——关键不在大小，而在你选的路径是否匹配当前环境。比如用 mysqldump 导出再导入 5000 万行 InnoDB 表，没调参的话很可能卡在单线程写入和频繁事务提交上；而用 xtrabackup 物理拷贝，同一份数据在千兆内网下通常 20–40 分钟就能完成全量复制。
会加锁，但不是所有SQL都加锁，也不是所有场景都加同一类锁。核心判断依据是：SELECT是否带FOR UPDATE或LOCK IN SHARE MODE、UPDATE/DELETE是否命中索引、当前事务隔离级别（尤其是READ COMMITTED和REPEATABLE READ）。
直接用 JOIN（等价于 INNER JOIN）连接两张或以上表时，必须明确指定连接条件，否则结果是笛卡尔积——这几乎总是错误的起点。
MySQL 的 InnoDB 默认用行锁，但很多情况下会 silently 升级成表锁——最常见的是在 WHERE 条件中使用了非索引字段或函数。比如执行 UPDATE user SET status=1 WHERE CONCAT(name, ”) = ‘alice’，即使 name 有索引，CONCAT 也会让优化器放弃索引，触发全表扫描+全表加锁。
是的，但只限于 log buffer 刷到 OS cache 并调用 fsync() 写入磁盘日志文件（ib_logfile0 等）——不是刷数据页，也不是刷 binlog。它不保证操作系统或磁盘固件没缓存，也不绕过存储栈的写缓存（比如 RAID 卡、NVMe 的 write cache）。如果磁盘掉电且未禁用写缓存，仍可能丢最后几条事务。
本质是它用触发器监听原表写入，再异步同步到新表，一旦原表写入压力大或网络延迟高，copy rows 就会明显滞后，甚至堆积。这不是 bug，是设计使然——它必须等所有变更都追平才能原子切换。