京公网安备11010502063487号本机真实开两个MySQL连接，一个事务里连续两次COUNT(*)，中途另一个连接真实插入并提交了新数据，验证REPEATABLE READ下同一个事务真实两次读到的是不是同一个结果。
本机真实把隔离级别切到READ COMMITTED，跑跟上一篇完全一样的两连接实验，看同一个事务里连续两次读到的结果是不是还一样。
本机真实用一个连接FOR UPDATE锁住一行，另外两个连接分别用普通SELECT和UPDATE去碰这一行，真实测出普通读0.0001秒不受影响、UPDATE被真实阻塞了1.5秒。
本机真实制造一个经典死锁：A锁行1想要行2，B锁行2想要行1，用SHOW ENGINE INNODB STATUS真实拿到InnoDB自己记录的死锁检测报告，看它真实选谁做牺牲品。
本机真实插入3行后开事务插入5行再ROLLBACK，看AUTO_INCREMENT计数器真实是不是也跟着回滚了——真实验证之后发现，下一条真实插入直接跳到了id=9，中间的编号永久消失。
本机真实建一张10万行的JSON表，在生成列city上建索引，对比直接查JSON路径表达式和查生成列的真实EXPLAIN与耗时，意外发现优化器能自动识别表达式等价但执行代价仍然不同。
本机真实用Python 3.14跑50个asyncio任务，真实验证它们全部只用了1个OS线程，并发50个任务的真实耗时(0.1s)跟串行50个任务的真实耗时(5s)差了50倍。
本机真实对比await两个裸协程(0.4023s)和await两个Task(0.2011s)的耗时差距，验证Task真实是在create_task那一刻就被调度上事件循环的，不是等你await才开始跑。
本机真实让1个任务用time.sleep(0.5)阻塞，另外3个任务只需要asyncio.sleep(0.1)，真实验证这3个任务被拖到了0.6秒才完成，跟全部用asyncio.sleep时的0.1秒完成形成鲜明对比。
本机真实跑一个CPU密集任务，单线程串行2.32秒，2个线程并发2.37秒（GIL下完全没提速），2个进程并发1.17秒（真实提速约2倍），10核CPU真实验证multiprocessing才能绕开GIL。
本机真实测Queue传输1000万个float64(0.19秒)、Pipe做2000次ping-pong(平均17微秒/次)、shared_memory让子进程零拷贝原地修改数组，三种跨进程通信方式真实的代价完全不同。
本机真实用同样4个CPU密集任务和4个IO密集任务分别跑ThreadPoolExecutor和ProcessPoolExecutor，验证CPU密集任务线程池2.13秒/进程池0.68秒，IO密集任务两者都在0.3秒左右。