innodb_buffer_pool_size通常设为物理内存的50%–75%，但必须预留至少2gb给系统及其他进程；80%是上限红线而非推荐值，混部或容器环境应保守取≤可用内存×60%。

innodb_buffer_pool_size 别设成物理内存的 80%

这是最常踩的坑：直接照搬“70%–80%”建议，在容器或混部环境里等于给 OOM Killer 递刀子。innodb_buffer_pool_size 只管 InnoDB 缓存，但 MySQL 还要吃线程栈、排序缓冲区、临时表、连接对象、performance_schema 内存监控等——加起来轻松再吞 1–2GB。

真实可用内存 = MemAvailable（不是 free -h 的 free 或 total） − 系统保留（至少 1GB）− 其他常驻进程（如日志 agent、Redis）− 容器 memory limit（如果用了 cgroup）

• 生产保守值：innodb_buffer_pool_size ≤ 可用内存 × 60%
• 小内存机器（≤4GB）直接设 1G 或 1.5G，别碰 75%
• 单位写 1G（MySQL 8.0+ 对单位敏感），别写 1024M
• 验证：启动后执行 SHOW ENGINE INNODB STATUS\G，看 Buffer pool size 和 Database pages 是否接近；再用 ps -o pid,vsz,rss,comm -C mysqld 观察 RSS，必须明显低于 cgroup limit 或 MemAvailable

tmp_table_size 和 max_heap_table_size 必须调低

云主机默认关 swap，OOM Killer 不会等，而是立刻干掉最大 RSS 进程——通常是 mysqld。而大查询建隐式内存临时表时，就靠这两个参数兜底。默认值（16M/16M）在复杂 JOIN 下几秒就能撑爆。

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• 统一设为 tmp_table_size = 64M、max_heap_table_size = 64M（注意单位是 M，不是 MB）
• 这两个值是 per-connection 的，100 个并发理论上最多消耗 6.4GB，必须纳入总内存预算
• 禁用 swap 时尤其关键：查 SHOW GLOBAL STATUS LIKE 'Created_tmp%tables'，若 Created_tmp_disk_tables 持续增长，说明临时表已落地磁盘——该优化 SQL，而不是加内存

必须用 cgroup v2 给 mysqld 设硬内存上限

MySQL 原生不支持用户级内存限制，MAX_USER_CONNECTIONS 只能防连接泄露，不能控内存。真正起效的是操作系统层的硬限。

• 仅靠配置 innodb_buffer_pool_size 不可靠：InnoDB 动态申请内存，OS page cache 也会推高实际 RSS
• Docker/Kubernetes 中只配 resources.limits.memory 不够，mysqld 看不到 cgroup 边界，仍按宿主机内存估算 buffer pool
• 推荐方案：用 systemd 的 MemoryMax（cgroup v2），例如 systemctl set-property mysqld.service MemoryMax=3G
• 验证：cat /sys/fs/cgroup/memory/$(systemd-cgtop | grep mysqld | awk '{print $1}')/memory.max

connection_memory_limit 是 MySQL 8.0.28+ 的熔断开关

它比 max_connections 更治本——后者调高反而加剧 OOM 风险，因为每个连接都独占 sort_buffer_size、join_buffer_size 等会话级缓冲区。

• 开启全局追踪：SET GLOBAL global_connection_memory_tracking = 1
• 设单连接硬限：SET PERSIST_ONLY connection_memory_limit = 2097152（2MB）
• 该限制只对无 SUPER 权限用户生效；超限时报错：ERROR 1105 (HY000): Memory limit exceeded for this connection
• 配合查 SELECT THREAD_ID, USER, CURRENT_MEMORY FROM performance_schema.memory_summary_by_thread_by_event_name WHERE CURRENT_MEMORY > 1048576，揪出吃内存的连接

真正危险的不是某个参数设得太高，而是多个内存源叠加后悄悄越过 MemAvailable —— 而这个值在云主机上往往比 free -h 显示的小得多。每次调参后，务必用 cat /proc/meminfo | grep MemAvailable 和 ps 实测 RSS，而不是依赖理论计算。