web-dev-qa-db-ja.com

MariaDB GaleraクラスターとMariaDBのSELECTパフォーマンスがひどい

私たちはGaleraのセットアップを評価していますが、ひどいREADパフォーマンスを持ついくつかのクエリを除いて、多くの欠点に気づいていません。

クエリ自体は実際には最適化されていませんが、プロダクションボックスでは0.20秒未満で戻ってきます。また、ガレラ3ノードのセットアップでは数分かかります。 （実際にははるかに強力なハードウェア上で）。

バージョンはガレラ用です：

mysqld  Ver 10.0.16-MariaDB-1~trusty-wsrep-log for 
debian-linux-gnu on x86_64 (mariadb.org binary distribution, wsrep_25.10.r4144)

そして、「古い」製品マシン用

mysqld  Ver 5.3.12-MariaDB-mariadb122~maverick for 
debian-linux-gnu on x86_64 ((MariaDB - http://mariadb.com/))

クエリ：

    MariaDB [ticketing]> EXPLAIN SELECT DISTINCT `purchase`.`id`,
 `purchase`.`invoiceid`, `purchase`.`userid`, `purchase`.`currencyid`, `purchase`.`purchasestatusid`, `purchase`.`isdeleted`,
 `purchase`.`emailshistory`, `purchase`.`created`,
 `purchase`.`paymentfee` FROM `purchase`  
INNER JOIN `payment` ON payment.purchaseid = purchase.id 
WHERE (invoiceid IS NULL) AND (purchasetypeid = 1) 
AND (purchase.created >= '2015-01-19 10:40:17') 
AND (paymenttypeid = 15) ORDER BY `created` DESC;
    +------+-------------+----------+--------+-------------------------------------------------------------------+-----------------+---------+------------------------------+-------+----------------------------------------------+
    | id   | select_type | table    | type   | possible_keys                                                     | key             | key_len | ref                          | rows  | Extra                                        |
    +------+-------------+----------+--------+-------------------------------------------------------------------+-----------------+---------+------------------------------+-------+----------------------------------------------+
    |    1 | SIMPLE      | payment  | ref    | purchaseid,paymenttypeid_2                                        | paymenttypeid_2 | 4       | const                        | 56344 | Using index; Using temporary; Using filesort |
    |    1 | SIMPLE      | purchase | eq_ref | PRIMARY,invoiceid,purchasetypeid,idx_active_purchases,idx_created | PRIMARY         | 4       | ticketing.payment.purchaseid |     1 | Using where                                  |
    +------+-------------+----------+--------+-------------------------------------------------------------------+-----------------+---------+------------------------------+-------+----------------------------------------------+
    2 rows in set (0.00 sec)

    MariaDB [ticketing]>

このように実行すると、次のようになります。

    +---------+-----------+--------+------------+------------------+-----------+---------------+---------------------+------------+
850 rows in set (0.17 sec)

MariaDB [ticketing]>

これをgaleraクラスターで実行すると、スローダウンは異常です。

+----------+--------------+---------+
1970 rows in set (5 min 16.64 sec)

このプロセスを追跡すると、プロセスはかなりビジーであるが、CPU使用率とメモリ使用量は低い（3％、2％）ことがわかります。パフォーマンスは、実稼働マシンと同じになると予想されます（これは、ガレラステージングノードの実行中もかなりビジーです）何もない）

一部のサーバー構成変数、各ガレラノードには12GのRAMがありますが、製品マシンには4Gしかない

# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.
# Read the manual for more InnoDB related options. There are many!
default_storage_engine  = InnoDB
# you can't just change log file size, requires special procedure
#innodb_log_file_size   = 50M
innodb_buffer_pool_size = 4096M
innodb_log_buffer_size  = 8M
innodb_file_per_table   = 1
innodb_open_files       = 1600
innodb_io_capacity      = 400
innodb_flush_method     = O_DIRECT

プラットフォームはgaleraのUbuntu 14:04 LTSで、本番は12.04です

Galera conf：

[mysqld]
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
query_cache_type=0
query_cache_size=0
bind-address=0.0.0.0

# Galera Provider Configuration
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_provider_options="gcache.size=1G"

# Galera Cluster Configuration
wsrep_cluster_name="my_test_cluster"
wsrep_cluster_address="gcomm://192.168.128.76,192.168.128.74,192.168.128.83"

# Galera Synchronization Congifuration
wsrep_sst_method=rsync
#wsrep_sst_auth=user:pass

# Galera Node Configuration
wsrep_node_address="192.168.128.74"
wsrep_node_name="ttmasterdb1"

wsrep_slave_threads=16

クエリの最適化について理解しているので、開発者に適切なクエリを記述させることについては多くの意見がありますが、システム管理者として、非最適なクエリがnon-galera DBで非常に優れたパフォーマンスを発揮する理由を説明できなければなりません。 5分は、0.17msと比べて本当に長い時間です。

これに関するすべての入力をありがとう。

[〜＃〜]更新[〜＃〜]

Txのコメントは既に、私もそれらの質問をしました、ここにいくつかの答えがあります：

データベースは古いサーバーからインポートされ、警告なしで正常にインポートされました。 AFAIKの説明はまったく同じですが、おそらく私がスタックする主な理由です。内容は少し異なりますが、ステージングとプロダクションの相違は時間によるものであり、これはとにかくインポート以来すでに発生しています。

すべてのGaleraノードも同じ動作を示します。少なくともそれは一貫しています。

これは生産説明です

MariaDB [ticketing]> EXPLAIN SELECT DISTINCT `purchase`.`id`, `purchase`.`invoiceid`, `purchase`.`userid`, `purchase`.`currencyid`, `purchase`.`purchasestatusid`, `purchase`.`isdeleted`, `purchase`.`emailshistory`, `purchase`.`created`, `purchase`.`paymentfee` FROM `purchase`  INNER JOIN `payment` ON payment.purchaseid = purchase.id WHERE (invoiceid IS NULL) AND (purchasetypeid = 1) AND (purchase.created >= '2015-01-19 10:40:17') AND (paymenttypeid = 15) ORDER BY `created` DESC;
+------+-------------+----------+--------+-------------------------------------------------------------------+-----------------+---------+------------------------------+-------+----------------------------------------------+
| id   | select_type | table    | type   | possible_keys                                                     | key             | key_len | ref                          | rows  | Extra                                        |
+------+-------------+----------+--------+-------------------------------------------------------------------+-----------------+---------+------------------------------+-------+----------------------------------------------+
|    1 | SIMPLE      | payment  | ref    | purchaseid,paymenttypeid_2                                        | paymenttypeid_2 | 4       | const                        | 56472 | Using index; Using temporary; Using filesort |
|    1 | SIMPLE      | purchase | eq_ref | PRIMARY,invoiceid,purchasetypeid,idx_active_purchases,idx_created | PRIMARY         | 4       | ticketing.payment.purchaseid |     1 | Using where                                  |
+------+-------------+----------+--------+-------------------------------------------------------------------+-----------------+---------+------------------------------+-------+----------------------------------------------+
2 rows in set (0.00 sec)

これは病期分類（ガレラ）の説明です。私には同じように見えます。

MariaDB [ticketingstaging]> EXPLAIN 
SELECT  DISTINCT `purchase`.`id`, `purchase`.`invoiceid`, `purchase`.`userid`,
        `purchase`.`currencyid`, `purchase`.`purchasestatusid`,
        `purchase`.`isdeleted`, `purchase`.`emailshistory`, `purchase`.`created`,
        `purchase`.`paymentfee`
    FROM  `purchase`
    INNER JOIN  `payment` ON payment.purchaseid = purchase.id
    WHERE  (invoiceid IS NULL)
      AND  (purchasetypeid = 1)
      AND  (purchase.created >= '2015-01-19 10:40:17')
      AND  (paymenttypeid = 15)
    ORDER BY  `created` DESC; 
+------+-------------+----------+--------+-------------------------------------------------------------------+-----------------+---------+-------------------------------------+-------+----------------------------------------------+
| id   | select_type | table    | type   | possible_keys                                                     | key             | key_len | ref                                 | rows  | Extra                                        |
+------+-------------+----------+--------+-------------------------------------------------------------------+-----------------+---------+-------------------------------------+-------+----------------------------------------------+
|    1 | SIMPLE      | payment  | ref    | purchaseid,paymenttypeid_2                                        | paymenttypeid_2 | 4       | const                               | 62898 | Using index; Using temporary; Using filesort |
|    1 | SIMPLE      | purchase | eq_ref | PRIMARY,invoiceid,purchasetypeid,idx_active_purchases,idx_created | PRIMARY         | 4       | ticketingstaging.payment.purchaseid |     1 | Using where                                  |
+------+-------------+----------+--------+-------------------------------------------------------------------+-----------------+---------+-------------------------------------+-------+----------------------------------------------+

ガレラ：

Create Table: CREATE TABLE `purchase` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `isdeleted` tinyint(1) NOT NULL DEFAULT '0',
  `currencyid` int(11) NOT NULL,
  `channelid` int(11) DEFAULT NULL,
  `mediapartnerid` int(11) DEFAULT NULL,
  `distributionid` int(11) DEFAULT NULL,
  `organizerid` int(11) DEFAULT NULL,
  `vattypeid` int(11) DEFAULT NULL,
  `purchasestatusid` int(11) NOT NULL DEFAULT '1',
  `purchasetypeid` int(11) NOT NULL DEFAULT '1',
  `userid` int(11) DEFAULT NULL,
  `sellerid` int(11) DEFAULT NULL,
  `mailingid` int(11) DEFAULT NULL,
  `invoiceid` int(11) DEFAULT NULL,
  `selectedpaymenttypeid_obsolete` int(11) DEFAULT NULL,
  `organizerpaymentid` int(11) DEFAULT NULL,
  `partnerpaymentid` int(11) DEFAULT NULL,
  `paymentfee` decimal(11,3) NOT NULL DEFAULT '0.000',
  `ticketsreleased` tinyint(1) NOT NULL DEFAULT '0',
  `invoicenum` char(11) DEFAULT NULL,
  `invoicemailed` tinyint(1) NOT NULL DEFAULT '0',
  `invoicerequested` tinyint(1) NOT NULL DEFAULT '0',
  `ogoneredirectedto` varchar(255) DEFAULT NULL,
  `ogoneredirectresponse` text,
  `adyenredirectresponse` text,
  `organizercomment` text,
  `systemcomment` text,
  `organizermailcomment` text,
  `paymenthistory` text,
  `isairmiles` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `emailshistory` text,
  `hasvouchers` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `reminderdate` datetime DEFAULT NULL,
  `onlyreleaseafter` datetime DEFAULT NULL,
  `ip` varchar(255) DEFAULT NULL,
  `sessionid` varchar(255) DEFAULT NULL,
  `ogoneclientcallbackurls` text,
  `shopid` int(11) DEFAULT NULL,
  `created` timestamp NULL DEFAULT NULL,
  `lastchange` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `userid` (`userid`),
  KEY `invoiceid` (`invoiceid`),
  KEY `currencyid` (`currencyid`),
  KEY `purchasetypeid` (`purchasetypeid`),
  KEY `purchasestatusid` (`purchasestatusid`),
  KEY `channelid` (`channelid`),
  KEY `selectedpaymenttypeid` (`selectedpaymenttypeid_obsolete`),
  KEY `mediapartnerid` (`mediapartnerid`),
  KEY `idx_active_purchases` (`purchasetypeid`,`isdeleted`,`ticketsreleased`,`purchasestatusid`),
  KEY `organizerpaymentid` (`organizerpaymentid`),
  KEY `partnerpaymentid` (`partnerpaymentid`),
  KEY `sellerid` (`sellerid`),
  KEY `idx_created` (`created`),
  KEY `idx_comb_purch_id` (`ticketsreleased`,`purchasetypeid`,`purchasestatusid`),
  KEY `purchase_ibfk_14` (`shopid`),
  KEY `distributionid` (`distributionid`),
  KEY `vattypeid` (`vattypeid`),
  KEY `organizerid` (`organizerid`),
  KEY `ticketsreleased` (`ticketsreleased`),
  KEY `isdeleted` (`isdeleted`),
  CONSTRAINT `FK_purchase_distribution123` FOREIGN KEY (`distributionid`) REFERENCES `distribution` (`id`),
  CONSTRAINT `FK_purchase_user` FOREIGN KEY (`organizerid`) REFERENCES `user` (`id`),
  CONSTRAINT `FK_purchase_vattype123` FOREIGN KEY (`vattypeid`) REFERENCES `vattype` (`id`),
  CONSTRAINT `purchase_ibfk_1` FOREIGN KEY (`currencyid`) REFERENCES `currency` (`id`),
  CONSTRAINT `purchase_ibfk_10` FOREIGN KEY (`organizerpaymentid`) REFERENCES `organizerpayment` (`id`),
  CONSTRAINT `purchase_ibfk_11` FOREIGN KEY (`partnerpaymentid`) REFERENCES `partnerpayment` (`id`),
  CONSTRAINT `purchase_ibfk_12` FOREIGN KEY (`sellerid`) REFERENCES `user` (`id`),
  CONSTRAINT `purchase_ibfk_14` FOREIGN KEY (`shopid`) REFERENCES `shop` (`id`),
  CONSTRAINT `purchase_ibfk_3` FOREIGN KEY (`invoiceid`) REFERENCES `invoice` (`id`),
  CONSTRAINT `purchase_ibfk_4` FOREIGN KEY (`purchasetypeid`) REFERENCES `purchasetype` (`id`),
  CONSTRAINT `purchase_ibfk_6` FOREIGN KEY (`purchasestatusid`) REFERENCES `purchasestatus` (`id`),
  CONSTRAINT `purchase_ibfk_7` FOREIGN KEY (`channelid`) REFERENCES `channel` (`id`),
  CONSTRAINT `purchase_ibfk_9` FOREIGN KEY (`mediapartnerid`) REFERENCES `mediapartner` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2510030 DEFAULT CHARSET=utf8

そして

    MariaDB [ticketingstaging]> show create table payment\G
*************************** 1. row ***************************
       Table: payment
Create Table: CREATE TABLE `payment` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `paymenttypeid` int(11) NOT NULL,
  `purchaseid` int(11) NOT NULL,
  `currencyid` int(11) NOT NULL,
  `distributionid` int(11) DEFAULT NULL,
  `banktransactionid` int(11) DEFAULT NULL,
  `reimbursementv2id` int(11) DEFAULT NULL,
  `paymentfeeschemeid` int(11) DEFAULT NULL,
  `isactive` tinyint(4) NOT NULL DEFAULT '1',
  `amount` decimal(11,3) DEFAULT NULL,
  `paymentfee` decimal(11,3) DEFAULT NULL,
  `totalamount` decimal(11,3) DEFAULT NULL,
  `isconfirmed` tinyint(4) NOT NULL DEFAULT '0',
  `confirmeddatetime` datetime DEFAULT NULL,
  `confirmedbyuserid` int(11) DEFAULT NULL,
  `status` varchar(20) DEFAULT NULL,
  `datereceivedbypaymentprovider` date DEFAULT NULL,
  `paymentproviderreportmatchinfo` text,
  `banktransactionmatchinfo` text,
  `comment` text,
  `instructioncomment` text,
  `created` timestamp NULL DEFAULT NULL,
  `lastchange` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `purchaseid` (`purchaseid`),
  KEY `banktransactionid` (`banktransactionid`),
  KEY `paymenttypeid_2` (`paymenttypeid`,`purchaseid`),
  KEY `currencyid` (`currencyid`),
  KEY `created` (`created`),
  KEY `distributionid` (`distributionid`),
  KEY `reimbursementv2id` (`reimbursementv2id`),
  KEY `paymentfeeschemeid` (`paymentfeeschemeid`),
  KEY `confirmedbyuserid` (`confirmedbyuserid`),
  KEY `isconfirmed` (`isconfirmed`,`confirmeddatetime`),
  CONSTRAINT `FK_payment_confirmedbyuserid` FOREIGN KEY (`confirmedbyuserid`) REFERENCES `user` (`id`),
  CONSTRAINT `FK_payment_distribution` FOREIGN KEY (`distributionid`) REFERENCES `distribution` (`id`),
  CONSTRAINT `FK_payment_paymentfeescheme` FOREIGN KEY (`paymentfeeschemeid`) REFERENCES `paymentfeescheme` (`id`),
  CONSTRAINT `FK_payment_reimbursementv2` FOREIGN KEY (`reimbursementv2id`) REFERENCES `reimbursementv2` (`id`),
  CONSTRAINT `payment_ibfk_1` FOREIGN KEY (`paymenttypeid`) REFERENCES `paymenttype` (`id`),
  CONSTRAINT `payment_ibfk_2` FOREIGN KEY (`purchaseid`) REFERENCES `purchase` (`id`),
  CONSTRAINT `payment_ibfk_3` FOREIGN KEY (`banktransactionid`) REFERENCES `banktransaction` (`id`),
  CONSTRAINT `payment_ibfk_4` FOREIGN KEY (`currencyid`) REFERENCES `currency` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1174354 DEFAULT CHARSET=utf8 COMMENT='InnoDB free: 2228224 kB; (`paymenttypeid`) REFER `ticketing/'

一体、ここにもプロダクションバージョンがあります。コメントのメモはかなり奇妙です。テーブルスキーマに配置するなんて変なこと

Mariadb 5.5

Create Table: CREATE TABLE `purchase` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `isdeleted` tinyint(1) NOT NULL DEFAULT '0',
  `currencyid` int(11) NOT NULL,
  `channelid` int(11) DEFAULT NULL,
  `mediapartnerid` int(11) DEFAULT NULL,
  `distributionid` int(11) DEFAULT NULL,
  `organizerid` int(11) DEFAULT NULL,
  `vattypeid` int(11) DEFAULT NULL,
  `purchasestatusid` int(11) NOT NULL DEFAULT '1',
  `purchasetypeid` int(11) NOT NULL DEFAULT '1',
  `userid` int(11) DEFAULT NULL,
  `sellerid` int(11) DEFAULT NULL,
  `mailingid` int(11) DEFAULT NULL,
  `invoiceid` int(11) DEFAULT NULL,
  `selectedpaymenttypeid_obsolete` int(11) DEFAULT NULL,
  `organizerpaymentid` int(11) DEFAULT NULL,
  `partnerpaymentid` int(11) DEFAULT NULL,
  `paymentfee` decimal(11,3) NOT NULL DEFAULT '0.000',
  `ticketsreleased` tinyint(1) NOT NULL DEFAULT '0',
  `invoicenum` char(11) DEFAULT NULL,
  `invoicemailed` tinyint(1) NOT NULL DEFAULT '0',
  `invoicerequested` tinyint(1) NOT NULL DEFAULT '0',
  `ogoneredirectedto` varchar(255) DEFAULT NULL,
  `ogoneredirectresponse` text,
  `adyenredirectresponse` text,
  `organizercomment` text,
  `systemcomment` text,
  `organizermailcomment` text,
  `paymenthistory` text,
  `isairmiles` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `emailshistory` text,
  `hasvouchers` tinyint(1) unsigned NOT NULL DEFAULT '0',
  `reminderdate` datetime DEFAULT NULL,
  `onlyreleaseafter` datetime DEFAULT NULL,
  `ip` varchar(255) DEFAULT NULL,
  `sessionid` varchar(255) DEFAULT NULL,
  `ogoneclientcallbackurls` text,
  `shopid` int(11) DEFAULT NULL,
  `created` timestamp NULL DEFAULT NULL,
  `lastchange` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `userid` (`userid`),
  KEY `invoiceid` (`invoiceid`),
  KEY `currencyid` (`currencyid`),
  KEY `purchasetypeid` (`purchasetypeid`),
  KEY `purchasestatusid` (`purchasestatusid`),
  KEY `channelid` (`channelid`),
  KEY `selectedpaymenttypeid` (`selectedpaymenttypeid_obsolete`),
  KEY `mediapartnerid` (`mediapartnerid`),
  KEY `idx_active_purchases` (`purchasetypeid`,`isdeleted`,`ticketsreleased`,`purchasestatusid`),
  KEY `organizerpaymentid` (`organizerpaymentid`),
  KEY `partnerpaymentid` (`partnerpaymentid`),
  KEY `sellerid` (`sellerid`),
  KEY `idx_created` (`created`),
  KEY `idx_comb_purch_id` (`ticketsreleased`,`purchasetypeid`,`purchasestatusid`),
  KEY `purchase_ibfk_14` (`shopid`),
  KEY `distributionid` (`distributionid`),
  KEY `vattypeid` (`vattypeid`),
  KEY `organizerid` (`organizerid`),
  KEY `ticketsreleased` (`ticketsreleased`),
  KEY `isdeleted` (`isdeleted`),
  CONSTRAINT `FK_purchase_distribution123` FOREIGN KEY (`distributionid`) REFERENCES `distribution` (`id`),
  CONSTRAINT `FK_purchase_user` FOREIGN KEY (`organizerid`) REFERENCES `user` (`id`),
  CONSTRAINT `FK_purchase_vattype123` FOREIGN KEY (`vattypeid`) REFERENCES `vattype` (`id`),
  CONSTRAINT `purchase_ibfk_1` FOREIGN KEY (`currencyid`) REFERENCES `currency` (`id`),
  CONSTRAINT `purchase_ibfk_10` FOREIGN KEY (`organizerpaymentid`) REFERENCES `organizerpayment` (`id`),
  CONSTRAINT `purchase_ibfk_11` FOREIGN KEY (`partnerpaymentid`) REFERENCES `partnerpayment` (`id`),
  CONSTRAINT `purchase_ibfk_12` FOREIGN KEY (`sellerid`) REFERENCES `user` (`id`),
  CONSTRAINT `purchase_ibfk_14` FOREIGN KEY (`shopid`) REFERENCES `shop` (`id`),
  CONSTRAINT `purchase_ibfk_3` FOREIGN KEY (`invoiceid`) REFERENCES `invoice` (`id`),
  CONSTRAINT `purchase_ibfk_4` FOREIGN KEY (`purchasetypeid`) REFERENCES `purchasetype` (`id`),
  CONSTRAINT `purchase_ibfk_6` FOREIGN KEY (`purchasestatusid`) REFERENCES `purchasestatus` (`id`),
  CONSTRAINT `purchase_ibfk_7` FOREIGN KEY (`channelid`) REFERENCES `channel` (`id`),
  CONSTRAINT `purchase_ibfk_9` FOREIGN KEY (`mediapartnerid`) REFERENCES `mediapartner` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2519375 DEFAULT CHARSET=utf8

そして

Create Table: CREATE TABLE `payment` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `paymenttypeid` int(11) NOT NULL,
  `purchaseid` int(11) NOT NULL,
  `currencyid` int(11) NOT NULL,
  `distributionid` int(11) DEFAULT NULL,
  `banktransactionid` int(11) DEFAULT NULL,
  `reimbursementv2id` int(11) DEFAULT NULL,
  `paymentfeeschemeid` int(11) DEFAULT NULL,
  `isactive` tinyint(4) NOT NULL DEFAULT '1',
  `amount` decimal(11,3) DEFAULT NULL,
  `paymentfee` decimal(11,3) DEFAULT NULL,
  `totalamount` decimal(11,3) DEFAULT NULL,
  `isconfirmed` tinyint(4) NOT NULL DEFAULT '0',
  `confirmeddatetime` datetime DEFAULT NULL,
  `confirmedbyuserid` int(11) DEFAULT NULL,
  `status` varchar(20) DEFAULT NULL,
  `datereceivedbypaymentprovider` date DEFAULT NULL,
  `paymentproviderreportmatchinfo` text,
  `banktransactionmatchinfo` text,
  `comment` text,
  `instructioncomment` text,
  `created` timestamp NULL DEFAULT NULL,
  `lastchange` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `purchaseid` (`purchaseid`),
  KEY `banktransactionid` (`banktransactionid`),
  KEY `paymenttypeid_2` (`paymenttypeid`,`purchaseid`),
  KEY `currencyid` (`currencyid`),
  KEY `created` (`created`),
  KEY `distributionid` (`distributionid`),
  KEY `reimbursementv2id` (`reimbursementv2id`),
  KEY `paymentfeeschemeid` (`paymentfeeschemeid`),
  KEY `confirmedbyuserid` (`confirmedbyuserid`),
  KEY `isconfirmed` (`isconfirmed`,`confirmeddatetime`),
  CONSTRAINT `FK_payment_confirmedbyuserid` FOREIGN KEY (`confirmedbyuserid`) REFERENCES `user` (`id`),
  CONSTRAINT `FK_payment_distribution` FOREIGN KEY (`distributionid`) REFERENCES `distribution` (`id`),
  CONSTRAINT `FK_payment_paymentfeescheme` FOREIGN KEY (`paymentfeeschemeid`) REFERENCES `paymentfeescheme` (`id`),
  CONSTRAINT `FK_payment_reimbursementv2` FOREIGN KEY (`reimbursementv2id`) REFERENCES `reimbursementv2` (`id`),
  CONSTRAINT `payment_ibfk_1` FOREIGN KEY (`paymenttypeid`) REFERENCES `paymenttype` (`id`),
  CONSTRAINT `payment_ibfk_2` FOREIGN KEY (`purchaseid`) REFERENCES `purchase` (`id`),
  CONSTRAINT `payment_ibfk_3` FOREIGN KEY (`banktransactionid`) REFERENCES `banktransaction` (`id`),
  CONSTRAINT `payment_ibfk_4` FOREIGN KEY (`currencyid`) REFERENCES `currency` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1178154 DEFAULT CHARSET=utf8 COMMENT='InnoDB free: 2228224 kB; (`paymenttypeid`) REFER `ticketing/'

キャッシュ変数5.5、本番

MariaDB [ticketing]> show variables like '%cache%';
+-------------------------------+----------------------+
| Variable_name                 | Value                |
+-------------------------------+----------------------+
| aria_pagecache_age_threshold  | 300                  |
| aria_pagecache_buffer_size    | 134217728            |
| aria_pagecache_division_limit | 100                  |
| binlog_cache_size             | 32768                |
| binlog_stmt_cache_size        | 32768                |
| have_query_cache              | YES                  |
| join_cache_level              | 2                    |
| key_cache_age_threshold       | 300                  |
| key_cache_block_size          | 1024                 |
| key_cache_division_limit      | 100                  |
| key_cache_segments            | 0                    |
| max_binlog_cache_size         | 18446744073709547520 |
| max_binlog_stmt_cache_size    | 18446744073709547520 |
| metadata_locks_cache_size     | 1024                 |
| query_cache_limit             | 131072               |
| query_cache_min_res_unit      | 4096                 |
| query_cache_size              | 33554432             |
| query_cache_strip_comments    | OFF                  |
| query_cache_type              | ON                   |
| query_cache_wlock_invalidate  | OFF                  |
| stored_program_cache          | 256                  |
| table_definition_cache        | 400                  |
| table_open_cache              | 400                  |
| thread_cache_size             | 128                  |
+-------------------------------+----------------------+

ガレラ

MariaDB [(none)]> show variables like '%cache%';
+--------------------------------+----------------------+
| Variable_name                  | Value                |
+--------------------------------+----------------------+
| aria_pagecache_age_threshold   | 300                  |
| aria_pagecache_buffer_size     | 134217728            |
| aria_pagecache_division_limit  | 100                  |
| aria_pagecache_file_hash_size  | 512                  |
| binlog_cache_size              | 32768                |
| binlog_stmt_cache_size         | 32768                |
| have_query_cache               | YES                  |
| Host_cache_size                | 128                  |
| innodb_disable_sort_file_cache | OFF                  |
| innodb_ft_cache_size           | 8000000              |
| innodb_ft_result_cache_limit   | 2000000000           |
| innodb_ft_total_cache_size     | 640000000            |
| join_cache_level               | 2                    |
| key_cache_age_threshold        | 300                  |
| key_cache_block_size           | 1024                 |
| key_cache_division_limit       | 100                  |
| key_cache_file_hash_size       | 512                  |
| key_cache_segments             | 0                    |
| max_binlog_cache_size          | 18446744073709547520 |
| max_binlog_stmt_cache_size     | 18446744073709547520 |
| metadata_locks_cache_size      | 1024                 |
| query_cache_limit              | 131072               |
| query_cache_min_res_unit       | 4096                 |
| query_cache_size               | 0                    |
| query_cache_strip_comments     | OFF                  |
| query_cache_type               | OFF                  |
| query_cache_wlock_invalidate   | OFF                  |
| stored_program_cache           | 256                  |
| table_definition_cache         | 400                  |
| table_open_cache               | 400                  |
| thread_cache_size              | 100                  |
+--------------------------------+----------------------+

私は常に同じノードを使用してこの情報を取得します。

これは興味深い事実かもしれません、クエリは遅延中に一時テーブルにcpyで固執します

| 714 | root        | server9:59763 | ticketingstaging | Query   |    24 | Copying to tmp table | SELECT DISTINCT `purchase`.`id`, `purchase`.`invoiceid`, `purchase`.`userid`, `purchase`.`currencyid |    0.000 |

提案ごとにキャッシュをオンにした後（デフォルトでは14.04 ubuntuではオフのように見えます）、かなり高速化できましたが、Webトランザクションでは許容できません。それは始まりであり、これがそのような効果をもたらすことができるとは思いませんでした。

950 rows in set (41.98 sec)

データサイズ

MariaDB [(none)]> SELECT table_name AS "Tables",  round(((data_length + index_length) / 1024 / 1024), 2) "Size in MB"  FROM information_schema.TABLES  WHERE table_schema = "ticketingstaging" ORDER BY (data_length + index_length) DESC;

+--------------+------------+
| Tables       | Size in MB |
+--------------+------------+
| purchase     |    4383.97 |
| ticket       |    2028.42 |
| ticketsync   |    1637.00 |
| promotioncode|    1501.23 |
| airmileslog  |     693.09 |
| barcode      |     550.19 |
| seat         |     458.63 |
| payment      |     408.13 |
| user         |     363.63 |
| answer       |     284.48 |

本番

+--------------+------------+
| Tables       | Size in MB |
+--------------+------------+
| purchase     |    4706.97 |
| ticket       |    2391.44 |
| ticketsync   |    2126.61 |
| promotioncode|    1603.97 |
| airmileslog  |     758.52 |
| barcode      |     649.20 |
| seat         |     544.67 |
| payment      |     485.27 |
| user         |     383.58 |
mysqlmariadbgalera
5
Glenn Plas

私は、いくつかのパラメータを変更することで、ほとんどの場合これを解決することができました。どうやら、少なくとも1回はテーブルを開いて、データベースをウォームアップする必要があるようです。これは、テーブルとデータベースがたくさんあるmysql 5以降、私がよく知っている動作です。

クエリの初回実行時もクエリの実行速度が遅くなります（TABLE CACHE IS OFF）。以下のパラメーターを変更すると、クエリの最初の実行時にのみ発生します。追加の実行試行その後、それはもはやこのスローダウンを示しません。以下のパラメータが役立ちました

[mysqld_safe]
open-files-limit = 65535

そして

[mysqld]
innodb_open_files       = 16384

table_cache = 800
table_open_cache = 40000
table_definition_cache = 3000
thread_cache_size = 50

その理由は、ここでinformation_schemeがボトルネックになっているためだと思います。テーブルがたくさんある場合の既知の問題であるAfaik。

2
Glenn Plas