MariaDB 10.4对大量查询进行微调

如何解决MariaDB 10.4对大量查询进行微调

我的服务器具有以下参数：

OS: Ubuntu 18.04.4 LTS x86_64
Kernel: 4.15.0-112-generic
cpu: Intel Xeon Silver 4214 (48 Cores) @ 2.201GHz
Memory: 96Gb
SSD SAMSUNG MZQLB960HAJR-00007 894.3Gb x 2

已安装5.5.5-10.4.12-MariaDB-1:10.4.12+maria~bionic。我有一个 PHP编写的项目，其中有很多数据库查询（每秒约400-500个SELECT +每秒约200-300 UPDATE）。问题是：在许多用户活动期间，数据库速度相当慢，但在其他任何时间都可以。我的my.cfg文件如下：

# this is read by the standalone daemon and embedded servers
[server]

# this is only for the MysqLd standalone daemon
[MysqLd]

#
# * Basic Settings
#
user = MysqL
pid-file = /var/run/MysqLd/MysqLd.pid
socket = /var/run/MysqLd/MysqLd.sock
port = 3306
basedir = /usr
datadir = /var/lib/MysqL
tmpdir = /tmp
lc-messages-dir = /usr/share/MysqL
skip-external-locking
skip-name-resolve
max_connections = 1000000
bind-address = 0.0.0.0

#
# * Fine Tuning
#
key_buffer_size = 96M
max_allowed_packet = 16M
thread_stack = 192K
thread_cache_size = 32

# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched
myisam-recover         = BACKUP

lock_wait_timeout = 10
interactive_timeout = 10
wait_timeout = 3

#
# * Query Cache Configuration
#
query_cache_type = 0
query_cache_limit = 0
query_cache_size = 0
open-files-limit = 320000
thread_cache_size = 64

#
# * Logging and Replication
#
log_error = /var/log/MysqL/error.log
expire_logs_days = 10
max_binlog_size = 100M

#
# * InnoDB
#

innodb_buffer_pool_size = 10000M
innodb_buffer_pool_instances = 128
max_heap_table_size = 1000M
tmp_table_size = 1000M
sort_buffer_size = 96M
innodb_sort_buffer_size = 96M
read_buffer_size = 96M

#
# * Character sets
#
character-set-server  = utf8mb4
collation-server      = utf8mb4_general_ci


# this is only for embedded server
[embedded]

[mariadb]
max_statement_time = 15
thread_handling = pool-of-threads
thread_pool_size = 48

最近，我更改了thread_handling = pool-of-threads和wait_timeout = 3：虽然性能有所提高，但总体上并没有解决问题。我将不胜感激如何加快速度或消除一些“瓶颈”。

更新：

使用InnoDB，而不是MyISAM

已经如此。

打开慢速日志以查找最慢的查询。

好吧，我所有的SELECTs都只调用一个表（〜500k记录，没有JOIN和/或子查询），而且大多数都具有LIMIT 1，因此没有那么多数据。

让我们看看“显示创建表”。

好吧，这里是此主表的SHOW CREATE TABLE：

CREATE TABLE `orders` (
  `id` int(11) NOT NULL AUTO_INCREMENT,`user_id` int(11) NOT NULL,`order_created_datetime` timestamp NULL DEFAULT current_timestamp(),`order_updated_datetime` timestamp NULL DEFAULT '0000-00-00 00:00:00' ON UPDATE current_timestamp(),`order_last_perform_datetime` timestamp NULL DEFAULT '0000-00-00 00:00:00',`order_category_id` tinyint(4) DEFAULT NULL,`order_url` text CHaraCTER SET utf8 DEFAULT NULL,`order_social_shortcode` varchar(128) CHaraCTER SET utf8 DEFAULT NULL,`order_social_id` varchar(128) DEFAULT NULL,`order_title` text DEFAULT NULL,`order_preview_pic` text DEFAULT NULL,`order_custom_data` text DEFAULT NULL,`order_price_usd` decimal(13,6) DEFAULT 0.000000,`order_daily_limit` int(11) DEFAULT 0,`order_hourly_limit` int(11) DEFAULT 0,`order_minute_limit` int(11) DEFAULT 0,`order_overall_limit` int(11) DEFAULT 0,`order_initial_social_counter` int(11) DEFAULT 0,`order_daily_counter` int(11) DEFAULT 0,`order_hourly_counter` int(11) DEFAULT 0,`order_minute_counter` int(11) DEFAULT 0,`order_overall_counter` int(11) DEFAULT 0,`order_allowed_countries` text CHaraCTER SET utf8 DEFAULT NULL,`order_forbidden_countries` text CHaraCTER SET utf8 DEFAULT NULL,`order_api` tinyint(4) DEFAULT 0,`order_reported` tinyint(4) DEFAULT 0,`order_active` tinyint(4) DEFAULT 1,`order_deleted` tinyint(4) DEFAULT 0,`order_deleted_datetime` timestamp NULL DEFAULT '0000-00-00 00:00:00',`order_deleted_user_id` int(11) DEFAULT NULL,`users_log_actions` longtext CHaraCTER SET utf8 COLLATE utf8_bin DEFAULT NULL,`users_log_hidden` longtext CHaraCTER SET utf8 COLLATE utf8_bin DEFAULT NULL,PRIMARY KEY (`id`) USING BTREE,KEY `index_user_id` (`user_id`) USING BTREE,KEY `index_order_category_id` (`order_category_id`) USING BTREE,KEY `index_order_deleted` (`order_deleted`) USING BTREE,KEY `index_order_active` (`order_active`) USING BTREE,KEY `index_order_social_id` (`order_social_id`) USING BTREE,KEY `index_users_log_actions` (`users_log_actions`(1024)) USING BTREE,KEY `index_users_log_hidden` (`users_log_hidden`(1024)) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=461811 DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC

innodb_buffer_pool_size可能太小-您有多少数据？ MariaDB有多少可用RAM？

MariaDB在独立服务器上运行，没有任何其他软件（PHP，Apache等）。因此，我在该服务器上有96Gb RAM，MariaDB可以使用所有这些。

innodb_buffer_pool_instances太大；应该是-buffer_pool_size / 1G

请您澄清一下吗？就我而言，应该是buffer_pool_size / 96Gb，还是？我认为buffer_pool_size在我的配置中具有默认值。

如果innodb_flush_log_at_trx_commit是什么值？

是1，但是我尝试了2，但没有结果。

解决方法

由于您正在使用innodb，因此需要首先调整一些innodb参数。

innodb_buffer_pool_size 太小，因为您有96 GB的RAM。可以给此变量至少50％，并减少 innodb_buffer_pool_instances 。

如果您可以承受1-2秒的数据丢失，则将 innodb_flush_log_at_trx_commit 的值设置为2。

将 max_allowed_packet 设置为256 M

将最大连接数减少到1000

将 tmp_table_size 设置为256M

将 sql_binlog 和 innodb_doublewrite 设置为0

注意： SELECT（@@ key_buffer_size + @@ query_cache_size + @@ innodb_buffer_pool_size + @@ innodb_log_buffer_size + @@ max_connections *（@@ read_buffer_size + @@ read_rnd_buffer_size + @@ sort_buffer_size + @@ join_buffer_size + @ bin + @@ thread_stack + @@ tmp_table_size））/（1024 * 1024 * 1024）AS MAX_MEMORY_GB; 应该小于总RAM的80％。