MySQL跨库INSERT需用全限定名database.table，源表可跨库读取，目标表须显式授权INSERT权限；字段应显式列出，避免*引发类型错配或字符集问题。
跨数据库 INSERT INTO 的语法结构
MySQL 允许直接在 INSERT INTO 语句中写全限定表名，格式为 database_name.table_name。只要当前连接用户对目标库有 INSERT 权限，且源表可读（同库或跨库），就能执行。
常见错误是误以为必须先 USE database_name 才能操作该库的表——其实完全不需要切换上下文。
- 源表可以来自任意已授权数据库，例如：
SELECT * FROM sales.orders - 目标表必须用全名，例如：
INSERT INTO analytics.order_summary ... - 如果目标库名含特殊字符或关键字，需用反引号包裹：
INSERT INTO `my-db`.log_table
权限与连接用户限制
跨库写入失败，90% 是权限问题，不是语法问题。MySQL 检查的是当前登录用户的全局权限和目标库级权限，而不是“当前 USE 的库”的权限。
典型报错：ERROR 1142 (42000): INSERT command denied to user 'app_user'@'%' for table 'order_summary'
- 必须显式授予目标库的
INSERT权限：GRANT INSERT ON analytics.* TO 'app_user'@'%'; - 不能只给
SELECT权限就指望能 INSERT 到另一库——读写权限独立控制 - 若使用
DEFINER存储过程，注意 definer 用户是否拥有目标库权限，而非调用者
INSERT ... SELECT 跨库时的字段隐式转换风险
当用 INSERT INTO target_db.t1 SELECT ... FROM source_db.t2 时，MySQL 不校验字段类型兼容性，仅按位置匹配列。类型不一致可能静默截断、四舍五入甚至插入默认值。
- 务必显式列出目标字段：
INSERT INTO analytics.summary (date, total) SELECT order_date, SUM(amount) FROM sales.orders ... - 避免
INSERT INTO t1 SELECT * FROM t2跨库使用，字段顺序/数量/类型稍有变动就会出错 - 注意时区、字符集差异：若源库用
utf8mb4_unicode_ci，目标库用latin1_swedish_ci，插入中文会变问号或报错
事务与锁行为不受跨库影响，但需留意隔离级别
跨库 INSERT ... SELECT 仍受当前会话事务控制，也遵循 InnoDB 的行锁机制。但要注意：锁只作用于实际访问的表，不会跨库加锁。
- 源表（
SELECT部分）和目标表（INSERT部分）分别加锁，互不影响 - 若
SELECT查询扫描大表，可能长时间持有源表读锁（取决于隔离级别），但不会阻塞目标库其他写入 - 复制环境里，跨库语句会完整记录到 binlog，从库重放时同样需要对应库存在且权限到位
跨库 INSERT 看似简单，真正卡住人的往往是权限漏配、字段没对齐、字符集不一致这三处。尤其在自动化脚本里，别依赖 * 或默认值，每一列都显式写出来，错一次比修十次临时方案还省时间。
