MariaDB 性能调优应该先看慢查询还是参数？

MariaDB 性能调优不要一上来就改几十个参数。更可靠的顺序是：先确认慢在哪里，再看执行计划和索引，最后才调整 InnoDB、连接数、临时表、排序缓冲等配置。参数调优像放大器，SQL 和索引方向对了，它能放大性能；方向错了，它只会把问题藏得更深。

追问

慢查询应该怎么打开和分析？

开启 slow_query_log，把 long_query_time 设置成符合业务的阈值。再按出现频率、扫描行数、总耗时排序，不要只盯单次最慢 SQL。

最关键的参数是哪个？

InnoDB 场景先看 innodb_buffer_pool_size，因为它影响数据页和索引页缓存命中率。专用数据库常按内存 60%-80% 估算，但要留空间给系统和连接线程。

索引优化有什么取舍？

高频 WHERE、JOIN、ORDER BY 列适合联合索引，但字段不是越多越好。索引会提升读，也会拖慢写入、占用磁盘。

max_connections 越大越好吗？

不是。它只允许更多连接进来，不代表数据库能同时跑更多重查询。连接过多会放大线程、内存和锁竞争。

sort_buffer_size 和 join_buffer_size 能随便调大吗？

它们通常是会话级参数，并发一高总内存会放大。只有确认瓶颈并估算过峰值连接数后，才适合小步调整。

写段配置

ini
slow_query_log=1
long_query_time=1
innodb_buffer_pool_size=8G

sql
EXPLAIN SELECT * FROM orders WHERE user_id=1001 ORDER BY created_at DESC;
CREATE INDEX idx_orders_user_created ON orders(user_id, created_at);