asyncmy 默认不支持 mysql 8.0+ 的 caching_sha2_password 认证，需降级为 mysql_native_password 或升级至 0.2.9+ 并启用 ssl=true/ auth_plugin='caching_sha2_password'。
asyncmy 连不上 MySQL 8.0+？先检查认证插件
asyncmy 默认不支持 MySQL 8.0+ 的 caching_sha2_password 认证方式，连上去直接报 Authentication plugin 'caching_sha2_password' is not supported。这不是驱动 bug，是协议层没实现该插件。
- 临时解决：在 MySQL 服务端把用户认证方式降级——执行
ALTER USER 'your_user'@'%' IDENTIFIED WITH mysql_native_password BY 'your_pass'; - 长期建议：改用
asyncpg？不行，asyncpg只支持 PostgreSQL，压根不连 MySQL —— 这里常有人搜错关键词，以为它是通用异步驱动 - asyncmy 0.2.9+ 已实验性支持
caching_sha2_password，但需手动开启：传参ssl=True或显式指定auth_plugin='caching_sha2_password'
asyncpg 根本不支持 MySQL，别试了
asyncpg 是纯 PostgreSQL 协议实现，和 MySQL 完全无关。搜 “asyncpg mysql” 很容易被误导，尤其看到 GitHub 上有同名但非官方的 fork 项目，那些要么已归档，要么只到 PoC 阶段，没维护、没测试、不能用于生产。
- 查文档最准：asyncpg 官网明确写 “A fast PostgreSQL database client for Python/asyncio”
- 装完 import
asyncpg后尝试连 MySQL，会立刻报ConnectionRefusedError或更底层的协议错误，因为端口（5432 vs 3306）和握手流程都不对 - 真要跨数据库异步抽象，得用
SQLAlchemy 2.0++aiomysql/asyncmy做适配层，而不是指望 asyncpg
asyncmy 在高并发 INSERT 场景下容易卡住
asyncmy 内部用了 asyncio 的 StreamReader 和自定义缓冲逻辑，在批量插入（比如 executemany）时，如果单次数据量大或网络延迟波动，容易触发读超时或连接假死，表现是协程挂起、CPU 低但无响应。
- 规避方法：拆小批次，每批控制在 100–500 行，加
timeout=10参数防死等 - 别依赖
connection.autocommit = False+ 手动commit()来提升吞吐——asyncmy 的事务状态管理不如 aiomysql 稳定，出错时 rollback 可能失败 - 若必须大批量写入，考虑先用
LOAD DATA LOCAL INFILE（需服务端开启local_infile）或走 Kafka + 同步消费者落库
性能差距没想象中大，但连接池行为很不一样
单纯比单条查询延迟，asyncmy 和 aiomysql 差距在 5%–15%，但连接池策略差异直接影响稳定性：asyncmy 的 create_pool 默认不校验连接有效性，空闲连接可能在 MySQL 的 wait_timeout 后变脏，下次复用就抛 Lost connection to MySQL server during query。
立即学习“Python免费学习笔记（深入）”；
- 必须显式配置
pool_recycle=3600（小于 MySQL 的 wait_timeout） - 开启
ping检测：在acquire时加await conn.ping()，但别在每次 query 前都 ping，开销大 - aiomysql 的 pool 更“保守”，默认会定期清理，asyncmy 则更轻量、也更需要你操心
asyncmy 不是 aiomysql 的简单替代，它绕过了 PyMySQL 层，直通二进制协议，所以初始化快、内存占用低，但调试时看不到中间 SQL 日志，出问题只能靠抓包或开 logging.getLogger("asyncmy").setLevel(logging.DEBUG) —— 这个开关很多人忘了开，排查时干瞪眼。
