减少每个请求的 MariaDB 查询时间

Question

关于

对于任何单个查询，MariaDB 服务器在大约 1 毫秒内完成每个请求。当并发增加时，每个请求的查询时间也会增加，直到超时。到目前为止，似乎只能为每个 mysql 服务器实例每秒进行大约 2k 的最大连接数，配置 tweeking 的数量似乎没有任何效果。有什么办法可以将每个客户端的查询时间减少不到 0.1ms？

这是查询

select ID from table where id=1;

如果有帮助，这里是mysql配置文件

[client]
port        = 3306
socket      = /home/user/mysql.sock
[mysqld]
port        = 3306
bind-address=127.0.0.1
datadir=/home/user/database
log-error=/home/user/error.log
pid-file=/home/user/mysqld.pid
innodb_file_per_table=1
back_log = 2000
max_connections = 1000000
max_connect_errors = 10
table_open_cache = 2048
max_allowed_packet = 16M
binlog_cache_size = 1M
max_heap_table_size = 64M
read_buffer_size = 2M
read_rnd_buffer_size = 16M
sort_buffer_size = 8M
join_buffer_size = 8M
thread_cache_size = 8
thread_concurrency = 200
query_cache_size = 64M
query_cache_type = 1 #My settings
innodb_io_capacity = 100000
query_cache_limit = 2M
ft_min_word_len = 4
default-storage-engine = innodb
thread_stack = 240K
transaction_isolation = REPEATABLE-READ
tmp_table_size = 64M
log-bin=mysql-bin
binlog_format=mixed
slow_query_log
long_query_time = 2
server-id = 1
key_buffer_size = 32M
bulk_insert_buffer_size = 64M
myisam_sort_buffer_size = 128M
myisam_max_sort_file_size = 10G
myisam_repair_threads = 1
myisam_recover
innodb_buffer_pool_size = 2G
innodb_data_file_path = ibdata1:10M:autoextend
innodb_doublewrite = 0
sync_binlog=0
skip_name_resolve
innodb_write_io_threads = 500
innodb_read_io_threads = 500
innodb_thread_concurrency = 1000
innodb_flush_log_at_trx_commit = 2
innodb_log_buffer_size = 8M
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 90
innodb_lock_wait_timeout = 120

[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash

[myisamchk]
key_buffer_size = 512M
sort_buffer_size = 512M
read_buffer = 8M
write_buffer = 8M

[mysqlhotcopy]
interactive-timeout

[mysqld_safe]
open-files-limit = 81920

硬件

2x Intel Xeon 2670 32 Gb RAM 500Gb ssd ssd samsung evo 850

绕道

虽然 MySql 每秒可以执行超过 100 万次查询，但测试 here 只执行了 250 个连接的客户端。

Answer 1

您的机器有 4 个核心，对吗？因此，如果同时运行超过 4 个 CPU 密集型进程，CPU 就会饱和。这意味着每个线程将被中断以让其他线程运行。也就是说，延迟增加。

您的目标是缩短平均查询时间吗？那是延迟？那么更多的连接将无济于事。

您的目标是每秒查询次数，那么，一旦 CPU 饱和，您将再次停止。这可能会在您达到 8 个连接之前发生。 CPU 饱和后，即使您增加连接数，吞吐量（查询数/秒）也会趋于平稳。但是，正如我已经说过的，单个查询的延迟会增加。

如果要推送机器，请在每个连接中执行多个查询。否则，您只需要对连接处理进行计时。这不是一个有用的指标。​​

如果您添加更多服务器（通过复制、集群等），您可以每秒运行更多查询。更多核心同上。但是没有什么可以大大减少单个查询所花费的时间。

在设置中，max_connections = 1000000 很可笑，可能会消耗大量 RAM。正如我所说，8 可能是您的基准测试所能处理的全部。

另一个设置...打开查询缓存具有欺骗性。它加快了运行相同SELECT如果有问题的表没有改变。也就是说，第一次运行查询可能需要 1.0ms；那么 same 查询的所有后续运行可能需要 0.1 毫秒。这不是一个非常令人兴奋的发现。执行两次查询 - 这将为您提供所有您可以学习的内容，而无需启动任何基准平台等。

但大多数生产机器发现 QC 没用。这是因为数据在变化，所以 QC 已经过时了。事实上，“清除”QC 的成本可能会使查询运行速度变慢！

如果您想要大量的读取连接，Replication Slaves 可以提供无限个连接。我曾经使用一个有 23 个从站的系统；这提供了 23 倍的连接。 Booking.com 的系统拥有超过 100 个奴隶。这就是您可以如此快速地查询酒店空房情况的方法。

请退后一步，想想你的真正目标是什么。然后我们可以进一步讨论。