在将大型(3+gb)数据库从mysql数据迁移到mariadb之后,它在特定的查询性能方面遇到了问题,它是64位版本。对数据库进行分析、优化、重建。下面是mariadb的配置、数据库方案和查询。
非常感谢您对解决这个问题的方法/方式/地点/时间的建议。
机器参数为:intel core i5 cpu@3.6ghz,16gb ram,sandisk 512gb ssd,使用windows 10 v.1909。
性能较慢的sql查询(10秒,在MySQL5.7上通常为1秒左右):
SELECT * FROM (
SELECT
'#AT&T' AS instrument,
(SELECT '2020-05-21 09:30' AS report_period) report_period,
#Average price
(SELECT AVG(avg_price.avg_price) AS avg_price FROM
(
SELECT AVG(t.CLOSE_PRICE) AS avg_price
FROM mt4_trades t
WHERE t.CLOSE_TIME BETWEEN '2020-05-21 09:30' AND DATE_ADD('2020-05-21 09:30', INTERVAL 119 SECOND) AND t.OPEN_TIME > '2012-08-26'
AND t.SYMBOL LIKE '#AT&T%' AND t.CMD IN (0,1)
UNION ALL
SELECT AVG(t.OPEN_PRICE) AS avg_price
FROM mt4_trades t
WHERE t.OPEN_TIME BETWEEN '2020-05-21 09:30' AND DATE_ADD('2020-05-21 09:30', INTERVAL 119 SECOND)
AND t.SYMBOL LIKE '#AT&T%' AND t.CMD IN (0,1)
) avg_price) avg_price,
#Total deals value
(
SELECT SUM(total_deals_value.total_deals_value) AS total_deals_value FROM (
SELECT SUM(t.VOLUME/100.0 * 1 * t.CLOSE_PRICE ) AS total_deals_value
FROM mt4_trades t
WHERE t.CLOSE_TIME BETWEEN '2020-05-21 09:30' AND DATE_ADD('2020-05-21 09:30', INTERVAL 119 SECOND) AND t.OPEN_TIME > '2012-08-26'
AND t.SYMBOL LIKE '#AT&T%' AND t.CMD IN (0,1)
UNION ALL
SELECT SUM(t.VOLUME/100.0 * 1 * t.OPEN_PRICE ) AS total_deals_value
FROM mt4_trades t
WHERE t.OPEN_TIME BETWEEN '2020-05-21 09:30' AND DATE_ADD('2020-05-21 09:30', INTERVAL 119 SECOND)
AND t.SYMBOL LIKE '#AT&T%' AND t.CMD IN (0,1)
) total_deals_value) AS total_deals_value) result
LEFT OUTER JOIN
(SELECT '#AT&T' AS instrument, @fd_time0 AS fd_time, @fd_price0 AS fd_price,
(@fd_volume0/100.0 * 1 * @fd_price0 ) AS fd_volume
FROM (
SELECT @fd_time0 := fd_time AS fd_time, @fd_volume0 := VOLUME AS VOLUME, @fd_price0 := PRICE AS PRICE
FROM
(SELECT MIN(t.CLOSE_TIME) AS fd_time, t.VOLUME, t.CLOSE_PRICE AS PRICE FROM mt4_trades t WHERE t.CLOSE_TIME BETWEEN
DATE_ADD('2020-05-21 09:30', INTERVAL 119 SECOND) AND '2020-05-21 11:30' AND t.OPEN_TIME > '2012-08-26'
AND t.SYMBOL LIKE '#AT&T%'
UNION ALL
SELECT MIN(t.OPEN_TIME) AS fd_time, t.VOLUME, t.OPEN_PRICE AS PRICE FROM mt4_trades t WHERE t.OPEN_TIME BETWEEN
DATE_ADD('2020-05-21 09:30', INTERVAL 119 SECOND) AND '2020-05-21 11:30'
AND t.SYMBOL LIKE '#AT&T%'
ORDER BY fd_time) first_deal WHERE first_deal.fd_time IS NOT NULL ORDER BY first_deal.fd_time ASC LIMIT 1
) AS first_deal) temp_result ON temp_result.instrument = result.instrument
sql查询说明:
为表创建sql:
CREATE TABLE `mt4_trades` (
`TICKET` INT(11) UNSIGNED NOT NULL,
`LOGIN` INT(11) UNSIGNED NOT NULL,
`SYMBOL` VARCHAR(16) NOT NULL DEFAULT '' COLLATE 'utf8_general_ci',
`DIGITS` TINYINT(3) UNSIGNED NOT NULL,
`CMD` TINYINT(3) UNSIGNED NOT NULL,
`VOLUME` MEDIUMINT(8) UNSIGNED NOT NULL,
`OPEN_TIME` DATETIME NOT NULL,
`OPEN_PRICE` FLOAT(12,0) NOT NULL,
`SL` FLOAT(12,0) NOT NULL,
`TP` FLOAT(12,0) NOT NULL,
`CLOSE_TIME` DATETIME NOT NULL,
`EXPIRATION` DATETIME NOT NULL,
`REASON` TINYINT(3) UNSIGNED NOT NULL DEFAULT '0',
`CONV_RATE1` FLOAT(12,0) NOT NULL,
`CONV_RATE2` FLOAT(12,0) NOT NULL,
`COMMISSION` FLOAT(12,0) NOT NULL,
`COMMISSION_AGENT` FLOAT(12,0) NOT NULL,
`SWAPS` FLOAT(12,0) NOT NULL,
`CLOSE_PRICE` FLOAT(12,0) NOT NULL,
`PROFIT` FLOAT(12,0) NOT NULL,
`TAXES` FLOAT(12,0) NOT NULL,
`COMMENT` VARCHAR(32) NOT NULL DEFAULT '' COLLATE 'utf8_general_ci',
`INTERNAL_ID` INT(11) NOT NULL,
`MARGIN_RATE` FLOAT(12,0) NOT NULL,
`TIMESTAMP` INT(11) UNSIGNED NOT NULL,
`MAGIC` INT(11) NOT NULL DEFAULT '0',
`GW_VOLUME` INT(11) NOT NULL DEFAULT '0',
`GW_OPEN_PRICE` INT(11) NOT NULL DEFAULT '0',
`GW_CLOSE_PRICE` INT(11) NOT NULL DEFAULT '0',
`MODIFY_TIME` DATETIME NOT NULL,
PRIMARY KEY (`TICKET`) USING BTREE,
INDEX `INDEX_STAMP` (`TIMESTAMP`, `COMMENT`) USING BTREE,
INDEX `CMD` (`CMD`, `OPEN_TIME`, `CLOSE_TIME`, `LOGIN`, `VOLUME`, `SYMBOL`, `CLOSE_PRICE`) USING
BTREE
)
COLLATE='utf8_general_ci'
;
mariadb的 my.ini
```
[mysqld]
port= 3306
socket = "C:/xampp/mysql/mysql.sock"
basedir = "C:/xampp/mysql"
tmpdir = "C:/xampp/tmp"
datadir = "C:/xampp/mysql/data"
log_error = "mysql_error.log"
pid_file = "mysql.pid"
collation_server=utf8_general_ci
character_set_server=utf8
CUSTOM EDIT
sql-mode=NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,NO_FIELD_OPTIONS,NO_KEY_OPTIONS,NO_TABLE_OPTIONS,STRICT_TRANS_TABLES
skip_external_locking
skip_name_resolve
max_connections = 200
table_open_cache = 10000
table_definition_cache = 2000
open_files_limit = 20000
MyISAM setting
key_buffer = 512M
myisam_sort_buffer_size = 2M
max_allowed_packet = 16M
max_sort_length = 16384
sort_buffer_size = 1M
net_buffer_length = 64K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
INNO DB settings
innodb_file_per_table = 1
innodb_buffer_pool_size = 4G
innodb_sort_buffer_size = 16M
Set .._log_file_size to 25 % of buffer pool size
innodb_log_file_size = 1024M
innodb_log_buffer_size = 32M
innodb_flush_log_at_trx_commit = 2
innodb_stats_on_metadata = 0
innodb_lock_wait_timeout = 600
innodb_flush_method = normal
A minor optimization when writing blocks to disk. Use 0 for SSD drives; 1 for HDD.
innodb_flush_neighbors = 0
innodb_io_capacity = 2000
innodb_buffer_pool_instances = 3
innodb_thread_concurrency = 12
innodb_autoextend_increment = 64
innodb_read_io_threads = 16
innodb_write_io_threads = 16
concurrent_insert = 2
thread_stack = 512K
interactive_timeout = 600
wait_timeout = 600
query_cache_type = 2
query_cache_limit = 64M
query_cache_min_res_unit = 1
query_cache_size = 16M
thread_cache_size = 128
low_priority_updates
tmp_table_size = 4M
max_heap_table_size = 4M
bulk_insert_buffer_size = 256M
group_concat_max_len = 512K
Define which query should be considered as slow, in seconds
long_query_time = 6
join_cache_level = 8
Size limit for the whole join
join_buffer_space_limit = 512M
join_buffer_size = 4M
Optimizer switches
optimizer_switch ='orderby_uses_equalities=on'
optimizer_switch ='mrr=on,mrr_sort_keys=on'
optimizer_switch ='index_merge_sort_intersection=on'
optimizer_switch ='optimize_join_buffer_size=on'
optimizer_switch ='join_cache_bka=on'
optimizer_switch ='join_cache_hashed=on'
optimizer_switch='in_to_exists=on'
optimizer_switch='join_cache_incremental=on'
optimizer_switch='loosescan=on'
Where do all the plugins live
plugin_dir = "C:/xampp/mysql/lib/plugin/"
server-id = 1
3条答案
按热度按时间mqxuamgl1#
这真是个疑问。我相信你需要把它分解一下才能了解它的性能。
在我看来,您有两个子查询模式。这里有一个模式
这是另一个
不幸的是,对于利用索引,您没有相等过滤器(
WHERE col=val
)在这些查询模式中。索引范围扫描可能非常有效,但当它们处理多个相等筛选器,然后处理一个范围筛选器时效果最好(time BETWEEN this AND that
)因此,为了优化,我们需要以具有最大选择性的列开始您的多列索引。我们需要为您的查询模式提供复合覆盖索引。
我想你应该试试这个索引作为你的第一个模式。
对于你的第二种模式,它更简单一点
您需要这两个索引,因为(我猜)您选择最多的列是
CLOSE_TIME
以及OPEN_TIME
. 你也应该试着CMD
在这些指标中排名第一;也许mariadb知道如何有效地使用索引CMD IN (0,1)
.关键是要使查询计划器能够单独满足来自索引的查询,而不必跳回表。
如果你能改变
SYMBOL LIKE 'value%'
至SYMBOL = 'value'
如果你的应用程序仍然正常工作,那么就这样做吧。然后把SYMBOL
在你的索引中排名第一;这是一个平等的匹配。(重要提示:在您的查询中
你得到了不可预测的价值量和收盘价。
(如果这是我为我的雇主处理别人钱的问题,我会花几个小时来分析它的正确性。)
0pizxfdo2#
在最近的mariadb和糟糕的查询中看到了这种行为(对不起,我不会粉饰它——有许多类似这样的子选择的查询只是糟糕的查询),我将在这里做一个猜测(因为您无法提供mysql 5.7中的explain计划):
切换
semijoin=off
在你的optimizer_switch
设置并查看它是否选择了一个不那么糟糕的执行计划。我也忍不住注意到,您正在切换许多配置设置-没有人需要接触这些设置的绝大多数,所以我建议您从一个干净的配置开始,只有
innodb_buffer_pool_size
根据您的内存大小进行适当的设置。pxq42qpu3#
不要在结尾使用(m,n)
FLOAT
或者DOUBLE
. 既然你有,0
,你不妨用一些INT
变体。索引
CMD
(CMD
,OPEN_TIME
,CLOSE_TIME
,LOGIN
,VOLUME
,SYMBOL
,CLOSE_PRICE
)--可能列太多了。我希望你们的table是innodb。
除非你有其他程序占用内存,否则你可以增加内存
innodb_buffer_pool_size
.这种模式通常效率低下:
FROM ( SELECT ... ) JOIN ( SELECT ... )
@fd_time0
--使用@variables是有风险的;优化器可能会带来惊喜;也就是说,您不能依赖于它们的设置和使用时间(他们最终将被禁止。)这个
UNION ALLs
似乎正好生成了两行,那么将这两个值相加?而不是UNION
这就形成了一个SUM
,请执行以下操作:这个
WHERE
有4个范围。只有一个可以使用索引:我建议您给优化器3个选择:
如果符号末尾不需要通配符,那么这些索引会更好:
(我的偏好)而不是
我更喜欢