Innodb：优化 10mb/sec 写入速度 48 小时后

Question

我在具有 NVME 存储 (2TB) 和 64 GB 内存的 8 核服务器上运行它。
磁盘速度极快，1.1 GB/秒 seq 和 70-100k IOPS 全双工。

因为 mysql 5.7 的性能太差，所以我在一个纤薄的 docker 容器上安装了 Mariadb 10.3.8。

我总共有 2 TB 和 10 亿行大小的表要写。但是让我明确一点：这种速度性能发生在前几千行的空磁盘上，与大表无关。

在过去的一周里，我日夜投入了大约50 个小时的工作，阅读了我能找到的每个文档页面以及各种平台上的数百个指南和问题。
我对它进行了全面测试，几乎可以采用任何您能想到的组合。
我尝试了纯内存缓冲，纯磁盘缓冲，有和没有大日志，日志缓冲区，各种刷新方法，不刷新，所有这些设置你可以想到。

我使用以下 方法测试了导入： mydumper、mysql 控制台、mysqlimport、加载数据 infile、PHP 插入、我编写的多线程 PDO 脚本。

我测试了有索引和没有索引的表，只有主索引。

我尝试使用和不使用 TRANSACTIONS导入，尝试单行和多行插入。

我尝试了不同的表类型，通常是 20-30 列，主要包含 varchars 和一些日期时间。

单线程的性能是 3-5k 行/秒，多线程（荒谬..）10-25k/秒。CPU和DISK大多一直处于空闲状态，iostat显示3-20mb/sec的写入性能，通常在7mb-12mb左右。取决于我尝试的设置。

所以比它应该执行的速度慢大约 100 倍，没有什么明显的阻碍它。
这是当前的配置：

innodb_buffer_pool_size = 14G
innodb_buffer_pool_chunk_size=1G
innodb_log_buffer_size  = 32M
innodb_file_per_table   = 1
innodb_open_files       = 600
#innodb_flush_method    = O_DIRECT
innodb_flush_method     = O_DSYNC 
innodb_log_file_size    = 512M
innodb_io_capacity=800 
innodb_io_capacity_max=3000 
innodb_flush_neighbors=0
innodb_write_io_threads=8 
innodb_read_io_threads=8 
innodb_change_buffer_max_size=70
innodb_doublewrite=0 # corruption risk

想象一下几乎所有可能的组合，我都试过了。

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvda              0.50         0.00        19.00          0         76
xvdg            102.50     13120.00         0.00      52480          0
xvdh           1381.50     19708.00     30984.00      78832     123936
xvdf              0.00         0.00         0.00          0          0
nvme0n1         222.00         0.00     10957.00          0      43828

这里唯一相关的磁盘是nvme0n1，可以看到当前使用多线程插入的写入性能。

| InnoDB |      | 
=====================================
2018-07-22 06:42:31 0x7fe7341c9700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 39 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 4883 srv_active, 0 srv_shutdown, 1061 srv_idle
srv_master_thread log flush and writes: 5944
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 2215493
OS WAIT ARRAY INFO: signal count 3968391
RW-shared spins 0, rounds 6388873, OS waits 1674234
RW-excl spins 0, rounds 34932124, OS waits 431565
RW-sx spins 13782, rounds 169207, OS waits 2879
Spin rounds per wait: 6388873.00 RW-shared, 34932124.00 RW-excl, 12.28 RW-sx
------------
TRANSACTIONS
------------
Trx id counter 1036891
Purge done for trx's n:o < 1036891 undo n:o < 0 state: running but idle
History list length 53
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 422106005755512, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
---TRANSACTION 422106005754696, not started
0 lock struct(s), heap size 1136, 0 row lock(s)
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (read thread)
I/O thread 7 state: waiting for completed aio requests (read thread)
I/O thread 8 state: waiting for completed aio requests (read thread)
I/O thread 9 state: waiting for completed aio requests (read thread)
I/O thread 10 state: waiting for completed aio requests (write thread)
I/O thread 11 state: waiting for completed aio requests (write thread)
I/O thread 12 state: waiting for completed aio requests (write thread)
I/O thread 13 state: waiting for completed aio requests (write thread)
I/O thread 14 state: waiting for completed aio requests (write thread)
I/O thread 15 state: waiting for completed aio requests (write thread)
I/O thread 16 state: waiting for completed aio requests (write thread)
I/O thread 17 state: waiting for completed aio requests (write thread)
Pending normal aio reads: [0, 0, 0, 0, 0, 0, 0, 0] , aio writes: [0, 0, 0, 0, 0, 0, 0, 0] ,
 ibuf aio reads:, log i/o's:, sync i/o's:
Pending flushes (fsync) log: 0; buffer pool: 0
263597 OS file reads, 2045302 OS file writes, 161983 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 282.56 writes/s, 28.08 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 1134, seg size 1136, 0 merges
merged operations:
 insert 0, delete mark 0, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0
Hash table size 4425293, node heap has 1 buffer(s)
Hash table size 4425293, node heap has 4113 buffer(s)
Hash table size 4425293, node heap has 1 buffer(s)
Hash table size 4425293, node heap has 41738 buffer(s)
Hash table size 4425293, node heap has 1 buffer(s)
Hash table size 4425293, node heap has 9223 buffer(s)
Hash table size 4425293, node heap has 1 buffer(s)
Hash table size 4425293, node heap has 5900 buffer(s)
7968.05 hash searches/s, 13692.47 non-hash searches/s
---
LOG
---
Log sequence number 185044128669
Log flushed up to   185044077028
Pages flushed up to 185040571130
Last checkpoint at  185017989085
0 pending log flushes, 0 pending chkp writes
37148 log i/o's done, 6.79 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total large memory allocated 17649631232
Dictionary memory allocated 419728
Buffer pool size   1048576
Free buffers       8032
Database pages     979545
Old database pages 361426
Modified db pages  275
Percent of dirty pages(LRU & free pages): 0.028
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 817, not young 38547
0.00 youngs/s, 0.00 non-youngs/s
Pages read 263539, created 1493647, written 2008209
0.00 reads/s, 204.33 creates/s, 275.76 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 979545, unzip_LRU len: 0
I/O sum[116336]:cur[0], unzip sum[0]:cur[0]
----------------------
INDIVIDUAL BUFFER POOL INFO
----------------------
---BUFFER POOL 0
Buffer pool size   131072
Free buffers       1025
Database pages     122400
Old database pages 45162
Modified db pages  19
Percent of dirty pages(LRU & free pages): 0.015
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 70, not young 6961
0.00 youngs/s, 0.00 non-youngs/s
Pages read 33027, created 186873, written 272369
0.00 reads/s, 19.72 creates/s, 32.72 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 122400, unzip_LRU len: 0
I/O sum[14542]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 1
Buffer pool size   131072
Free buffers       1007
Database pages     122444
Old database pages 45179
Modified db pages  26
Percent of dirty pages(LRU & free pages): 0.021
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 74, not young 9194
0.00 youngs/s, 0.00 non-youngs/s
Pages read 32952, created 187093, written 242787
0.00 reads/s, 22.49 creates/s, 28.87 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 122444, unzip_LRU len: 0
I/O sum[14542]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 2
Buffer pool size   131072
Free buffers       1023
Database pages     122421
Old database pages 45170
Modified db pages  14
Percent of dirty pages(LRU & free pages): 0.011
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 45, not young 177
0.00 youngs/s, 0.00 non-youngs/s
Pages read 32936, created 186494, written 236773
0.00 reads/s, 23.97 creates/s, 30.69 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 122421, unzip_LRU len: 0
I/O sum[14542]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 3
Buffer pool size   131072
Free buffers       994
Database pages     122454
Old database pages 45182
Modified db pages  39
Percent of dirty pages(LRU & free pages): 0.032
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 173, not young 254
0.00 youngs/s, 0.00 non-youngs/s
Pages read 33012, created 185887, written 258491
0.00 reads/s, 26.49 creates/s, 39.49 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 122454, unzip_LRU len: 0
I/O sum[14542]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 4
Buffer pool size   131072
Free buffers       1006
Database pages     122449
Old database pages 45180
Modified db pages  46
Percent of dirty pages(LRU & free pages): 0.037
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 120, not young 12679
0.00 youngs/s, 0.00 non-youngs/s
Pages read 32937, created 187265, written 249442
0.00 reads/s, 29.79 creates/s, 39.18 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 122449, unzip_LRU len: 0
I/O sum[14542]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 5
Buffer pool size   131072
Free buffers       1012
Database pages     122452
Old database pages 45182
Modified db pages  25
Percent of dirty pages(LRU & free pages): 0.020
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 202, not young 5093
0.00 youngs/s, 0.00 non-youngs/s
Pages read 32867, created 187025, written 253352
0.00 reads/s, 30.69 creates/s, 40.20 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 122452, unzip_LRU len: 0
I/O sum[14542]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 6
Buffer pool size   131072
Free buffers       1021
Database pages     122423
Old database pages 45171
Modified db pages  13
Percent of dirty pages(LRU & free pages): 0.011
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 64, not young 2573
0.00 youngs/s, 0.00 non-youngs/s
Pages read 32909, created 187403, written 243809
0.00 reads/s, 25.82 creates/s, 31.64 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 122423, unzip_LRU len: 0
I/O sum[14542]:cur[0], unzip sum[0]:cur[0]
---BUFFER POOL 7
Buffer pool size   131072
Free buffers       944
Database pages     122502
Old database pages 45200
Modified db pages  93
Percent of dirty pages(LRU & free pages): 0.075
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 69, not young 1616
0.00 youngs/s, 0.00 non-youngs/s
Pages read 32899, created 185607, written 251186
0.00 reads/s, 25.36 creates/s, 32.97 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 122502, unzip_LRU len: 0
I/O sum[14542]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
0 read views open inside InnoDB
Process ID=21173, Main thread ID=140612953028352, state: sleeping
Number of rows inserted 68789564, updated 0, deleted 0, read 0
10659.42 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
Number of system rows inserted 0, updated 0, deleted 0, read 0
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT

Mysql 就好像它有一个大约 25MB 写入/秒的内部 IO 限制。

我知道我没有添加基准，我已经连续工作了 20 个小时，但手头没有结果。请相信我的磁盘非常快。分配给 mysql 的内存不起作用，我从 1 GB 到 50.. 没有区别。

我花了半个星期和 16 个小时的轮班来让这个运行起来，我已经无能为力了。
我能想到的最后一件事是购买像 Oracle 这样的商业数据库，但这是另一个要经历的噩梦。

只有一次我的速度可以接受： 导入 IBD 文件“RAW”然后使用 IMPORT TABLESPACE 时。但这需要在源数据库上锁定数小时才能获取二进制快照，然后将其复制过来（需要通过网络花费时间），然后重新导入。
IMPORT TABLESPACE 性能本身还可以，大约 600 MB/秒
总的来说，这是最快的，但对我的原因来说它是不可用的。

这里的表：

    CREATE TABLE `eval` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `intern_id` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `first_name` varchar(64) COLLATE utf8_bin DEFAULT NULL,
  `last_name` varchar(64) COLLATE utf8_bin DEFAULT NULL,
  `middle_name` varchar(64) COLLATE utf8_bin DEFAULT NULL,
  `location` varchar(196) COLLATE utf8_bin DEFAULT NULL,
  `i` varchar(128) COLLATE utf8_bin DEFAULT NULL,
  `e` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `country_code` varchar(4) COLLATE utf8_bin DEFAULT NULL,
  `country_name` varchar(64) COLLATE utf8_bin DEFAULT NULL,
  `state_name` varchar(64) COLLATE utf8_bin DEFAULT NULL,
  `city_name` varchar(64) COLLATE utf8_bin DEFAULT NULL,
  `education` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `num_c` smallint(6) DEFAULT NULL,
  `num_j` smallint(6) DEFAULT NULL,
  `j_t` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `c_name` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `e_a` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `flag_existent` tinyint(4) DEFAULT NULL COMMENT '1/0',
  `public_p_u` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `c_intern_id` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `unmatched_facts` varchar(2048) COLLATE utf8_bin DEFAULT NULL,
  `dt_snapshot` datetime DEFAULT NULL,
  `change_small` tinyint(4) DEFAULT NULL,
  `change_significant` tinyint(4) DEFAULT NULL,
  `j_t_auth` varchar(256) COLLATE utf8_bin DEFAULT NULL COMMENT 'sure about it',
  `c_name_auth` varchar(256) COLLATE utf8_bin DEFAULT NULL COMMENT 'sure about it',
  `c_intern_id_guess` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `ut_created` int(11) DEFAULT NULL,
  `reserve_int_2` int(11) DEFAULT NULL,
  `reserve_vc1` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `reserve_vc2` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  `reserve_vc_3` varchar(256) COLLATE utf8_bin DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `intern_id` (`intern_id`),
  KEY `location` (`location`),
  KEY `country_name` (`country_name`),
  KEY `country_name_location_notnull` (`country_name`(1),`location`(1)),
  KEY `location_country_name` (`location`,`country_name`(1)),
  KEY `location_null_country_name` (`location`(1),`country_name`),
  KEY `dt_snapshot` (`dt_snapshot`),
  KEY `state_name` (`state_name`),
  KEY `city_name` (`city_name`),
  KEY `c_name` (`c_name`),
  KEY `c_name_auth` (`c_name_auth`),
  KEY `j_t` (`j_t`)
) ENGINE=InnoDB AUTO_INCREMENT=19883676 DEFAULT CHARSET=utf8 COLLATE=utf8_bin |

我测试了没有索引的导入，只有主键和完整索引。基本上速度总是一样的。唯一的区别是磁盘 IO 速度随着索引的增加而增加，但行/秒保持不变。

更新
使用“IMPORT TABLESPACE”导入表工作得很快（可怕的方法，需要删除 IBD 文件，任何中断都会破坏表，而且我必须锁定主要源数据库一个小时）
这种方法允许大约 350k 行/秒。

现在我正在使用服务器上加载的数据库，使用需要全表扫描的简单 SELECTS。(count(*) where xxx is not null)
数据库仅以 100mb/秒的速度进行全表扫描！
有一个瓶颈限制了可能的 90% 的速度。

更新：
我试图通过创建 5 个数据库会话来解决 QUERY 性能瓶颈，对同一个数据库表执行 SELECT 查询，但按 ID 分隔查询。1-10000000, 1000000-2000000, 300000-4000000 等等。每个单独的会话增加了 100mb/sec 的磁盘负载。
因此，数据库使用 5 个并发选择查询/会话比使用一个查询快 5 倍。
但实际上这应该慢得多。这意味着需要大量随机 IO，因为 5 个线程在不同位置快速访问同一个文件，因此可能需要较少的顺序 IO。

我在 WRITE 方面遇到了类似的问题，向 SAME 数据库文件写入 5 次比向其写入 1 次快 5 倍，但是它以非常慢的速度饱和（最高速度的 1-5%）

1 在桌子上选择：

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.21    0.00    0.35   10.66    0.26   87.52

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvda              0.67         0.00        21.33          0         64
xvdg              0.00         0.00         0.00          0          0
xvdh            134.33         5.33       721.33         16       2164
xvdf              4.67         0.00        25.33          0         76
nvme0n1        7032.00    112512.00         0.00     337536          0

5 在 SAME 表上不同的主键位置选择：

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           1.98    0.00    0.63   43.35    0.77   53.28
    Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
    xvda              0.67         0.00        22.67          0         68
    xvdg              0.00         0.00         0.00          0          0
    xvdh            111.33        13.33       598.67         40       1796
    xvdf              0.00         0.00         0.00          0          0
    nvme0n1       30051.33    480821.33         0.00    1442464          0

最新结论 这个问题似乎是 MySQL 和 MariaDB 内部的一个缺陷，可能是单线程设计引起的。
似乎随着列数的增加，最大性能会降低，每一列都会导致一些延迟开销。
InnoDb/XtraDb 似乎不是问题。这是目前我能找到的唯一解释，除了编写多线程自定义代码外，没有可能的解决方案。

所有全局变量和显示状态：https :
//paste.ee/p/Yk1Le

这里是整个配置文件（当前的变体，我尝试了所有我认为的）

[client]
port            = 3316
socket          = /maincache/share/mysqld.sock


[mysqld_safe]
socket          = /maincache/share/mysqld.sock
nice            = 0

[mysqld]
pid-file        = /var/run/mysqld/mysqld.pid
socket          = /maincache/share/mysqld.sock
port            = 3316
basedir         = /usr
datadir         = /var/lib/mysql
tmpdir          = /instance_store/tmp
lc_messages_dir = /usr/share/mysql
lc_messages     = en_US
skip-external-locking
bind-address            = 127.0.0.1
max_connections         = 100
connect_timeout         = 5
wait_timeout            = 600
max_allowed_packet      = 160M
thread_cache_size       = 128
sort_buffer_size        = 4M
bulk_insert_buffer_size = 16M
tmp_table_size          = 16M
max_heap_table_size     = 16M
join_buffer_size=32k
sort_buffer_size=32k
myisam_recover_options = BACKUP
key_buffer_size         = 6M
table_open_cache        = 1000
table_open_cache_instances = 8
myisam_sort_buffer_size = 16M
concurrent_insert       = 2
read_buffer_size        = 2M
read_rnd_buffer_size    = 1M
query_cache_limit               = 16M
query_cache_size                = 256M
log_error = /maincache/share/cluster/mysql_error.log
slow_query_log_file     = /var/log/mysql/mariadb-slow.log
long_query_time = 10

expire_logs_days        = 10
max_binlog_size         = 100M
default_storage_engine  = InnoDB
innodb_force_recovery=1
innodb_buffer_pool_size = 10G
innodb_buffer_pool_chunk_size=512M
innodb_file_per_table   = 1
innodb_open_files       = 600
innodb_flush_method     = O_DIRECT_NO_FSYNC
innodb_log_file_size    = 512M
innodb_io_capacity=5000
innodb_io_capacity_max=80000
innodb_flush_neighbors=0
innodb_write_io_threads=64
innodb_read_io_threads=64
innodb_change_buffer_max_size=70
innodb_buffer_pool_instances=128
innodb_thread_concurrency=144

[galera]

[mysqldump]
quick
quote-names
max_allowed_packet      = 16M

[mysql]

[isamchk]
key_buffer              = 16M

服务器有 64GB 的内存，但我在这个变体中将 mysql 服务器限制为 10GB。无论 innodb 缓冲区如何，它在性能上绝对没有差异。服务器处于空闲状态，在插入期间也是 80-90% 空闲（IO/cpu），当然没有交换。

Answer 1

现在已经过去了 2 年，多个 SQL 版本升级已经通过，并且测试了 5 个不同的高性能服务器（基本上是 AWS 提供的存储和 CPU 最快的服务器）。

从mysql 5.7的跳转。mysql 8 性能下降，这一变化的唯一好处是更复杂的 SQL 支持，但在性能方面没有任何改善。
好吧，count(*) 现在很快，它使用多线程，但只有在不使用 WHERE 条件的情况下，这使它更像是一个笑话，而不是真正的改进。

经过数周的分析和测试参数和优化的任意组合，我可以验证我最初的疑虑：问题来自于 Mysql 资源的高度低效使用（当前为 8.0.19 Percona）
操作是单线程且未优化，具体取决于您的情况准确地计算行写入之间的延迟非常重要。

我发现了两个“解决方案”，因为在我所拥有的时间内不可能从 Mysql 更改为更好的数据库服务器：

1. 对于具有近乎无限的 IOPS 和数十个 CPU 核心的非常强大的服务器，最快的插入方法是将数据拆分为块（取决于 100-10000 个表和数据块）并将它们并行插入到服务器中。
   像 xargs 或 Linux 上的并行这样的工具很有帮助（seq 0 100000| xargs .. mysql insert where id between ）
   尽管这是处理高性能服务器的最低效方法之一（极端 IOPS 使用、大量锁定、纯随机）写入与主键集群没有很好地对齐）这可以将性能提高 10 到 100 倍。
   我确实遇到过需要几周时间才能在几个小时内完成的 INSERT 查询。

解决方案1仅适用于具有大量空闲资源的服务器，就像我的问题一样，当你有90+%的服务器资源空闲时，为什么mysql基本上在单线程循环中执行sleep()。
Mysql 在解析 SQL 时存在巨大的性能瓶颈，每个 INSERTed 行都会调用解析器，该解析器似乎有一半的时间在执行 sleep()

2. 考虑到你的服务器没有那么大的空闲资源，例如我有200k IOPS数据存储但只有4个CPU核心的服务器。在这些情况下，并行插入将很快使您的 CPU 饱和，并且您的 IOPS 将被浪费。就像我提到的，mysql 的 SQL 解析效率非常低。
   在这些情况下，我已经尝试了很多，加载数据比插入更快，但自动化是一个巨大的麻烦，而且速度改进很小。加载数据也会像电影院里的爆米花一样浪费 CPU 周期。
   在这些情况下，最快的解决方案是 IMPORT TABLESPACE。
   这意味着我们又回到了单线程写入和读取（DOS 游戏性能提示计数），但读取现在是顺序的，而写入只是更改一个数字，因此该表集成在有点尴尬的内部 innodb 存储中（缺少那些 innodb 热副本） ， 正确的？）

旁注：

1. 不管你做什么，mysql就像一个古老的DOS游戏。它使用一个核心。
   因此，在选择服务器时，您应该关注高单核性能，这会产生显着的差异。
2. 使用 IMPORT TABLESPACE 或 LOAD DATA 时，不得将任何类型的二进制列（blob）与表压缩结合使用。Mysql 8 存在未纠正的错误，导致在处理与 blob 结合的表空间压缩 (ROW_FORMAT=compressed) 时出现段错误（信号 11）。
   这是一个罕见的错误，您可能不会在前 200 万行中遇到它，但有一天您会遇到 mysql 段错误，这可能会导致整个数据库中的隐藏表损坏，并且可能会丢失最近的数据，具体取决于错误和您的配置。（从 8.0 到 8.0.19+ 存在错误）
3. 请记住，对于 mysql 单一操作，单 CPU 核心性能胜过一切。如果您有数百个并发连接，情况就会发生变化，多线程和 IOPS 会发挥更大的作用。但每个连接只能以单个核心允许的速度运行。