是的，批量插入后查不到新数据绝大多数是因为事务未提交。SQL批量插入不自动提交，同一事务外会话默认不可见；需显式COMMIT或启用AUTOCOMMIT，ORM需调用commit()，且隔离级别影响可见性。
批量插入时新数据查不到，是不是事务没提交？
绝大多数情况下是的。SQL 批量插入（比如 INSERT INTO ... VALUES (...), (...), ...）本身不自动提交，只要还在同一事务里，其他会话默认看不到这些行——哪怕你刚执行完 INSERT 并立刻在另一个窗口 SELECT，也查不到。
常见错误现象：INSERT 返回成功，但紧接着 SELECT COUNT(*) 为 0；或应用层写入后调用查询接口，返回空结果。
- 确认是否显式执行了
COMMIT（MySQL/PostgreSQL）或END TRANSACTION（SQL Server） - 检查客户端是否启用了自动提交（
AUTOCOMMIT=ON），Python 的psycopg2默认关，mysql-connector-python默认开 - ORM 如 SQLAlchemy 默认不自动提交，
session.add_all()后必须session.commit()
READ COMMITTED 下批量插入后能被其他事务读到吗？
能，但仅限于已提交的数据。这是大多数数据库（PostgreSQL、SQL Server、Oracle）的默认隔离级别，也是 MySQL InnoDB 在非可重复读场景下的行为基础。
关键点在于“已提交”：即使你在本事务中分多批 INSERT，只要没 COMMIT，其他事务就完全不可见；一旦 COMMIT，所有这批数据原子性地对其他事务可见。
- MySQL 5.7+ 默认是
REPEATABLE READ，不是READ COMMITTED，所以即使你COMMIT了，另一个事务如果在它自己的事务开始后没SELECT过，首次SELECT仍可能看到旧快照 - PostgreSQL 的
READ COMMITTED每条语句都重新获取快照，所以COMMIT后下一条SELECT就能查到 - 避免依赖“插入后立刻可读”，尤其跨服务调用时，应以明确的
COMMIT+ 重试逻辑兜底
用 LOAD DATA INFILE 或 COPY 批量导入时，数据什么时候可见？
跟普通 INSERT 一样：取决于事务控制。这两个命令本质仍是 DML 操作，只是底层做了优化。
容易踩的坑是误以为“文件导入 = 立即生效”。实际上：
-
LOAD DATA INFILE（MySQL）默认在当前事务中执行，未COMMIT就不可见；加LOCAL也不改变事务语义 -
COPY（PostgreSQL）同样受事务控制，COPY ... FROM STDIN在事务块内执行，COMMIT前其他会话查不到 - 某些数据库提供“无日志”或“最小日志”模式（如 SQL Server 的
INSERT ... SELECTwithTABLOCK），但可见性规则不变，只是减少了锁和日志开销
高并发下批量插入 + 紧接着 SELECT，为什么偶尔查不到？
不是网络延迟，也不是缓存，大概率是读写事务交错 + 隔离级别导致的快照不一致。
典型场景：服务 A 批量插入 1000 条并 COMMIT，服务 B 几乎同时启动一个长事务，它的第一次 SELECT 获取的是事务开始时刻的快照，哪怕 A 已提交，B 仍看不到。
- PostgreSQL 中可通过
SELECT pg_backend_pid(), now();和SELECT * FROM pg_stat_activity WHERE backend_start 排查长事务 - MySQL 中检查
SHOW PROCESSLIST和information_schema.INNODB_TRX表里的TRX_STARTED - 最稳妥的做法是：写入方返回前确保
COMMIT成功；读取方不做“写完立刻读”的假设，改用带重试的最终一致性查询（例如等待最多 200ms，查不到则 sleep 后再试）
事务边界和隔离级别的组合影响远比看起来复杂，别指望靠“多试几次”绕过去——得看清谁在哪个快照里看什么。
