頻繁にクエリされる100,000レコードのMySQLテーブル


11

私はさまざまな種類の情報を格納するために、約100個のテーブルの単一のデータベースを持っています。

最も重要なテーブルは、顧客の注文を格納するために使用される注文テーブルであり、現在および増加している現在では10万件を超えるレコードです。

このテーブルは、リアルタイム注文ダッシュボード、統計、分析などから必要な情報のさまざまな部分について、データベースで最もクエリの多いテーブルです。

私は定期的にデータベースを監視しており、問題を追跡するためにデータベースで遅いクエリを有効にしています。

私はmysqltunerのようなスクリプトを使用して、毎日クエリを吐き出しています。

また、mysqlslaを使用して、データベース内の最も遅い10個のクエリに関する情報を収集します。

sample stat
Count         : 11.48k  (30.66%)
Time          : 19.623758 s total, 1.709 ms avg, 239 µs to 2.475017 s max  (18.64%)
  95% of Time : 5.246833 s total, 481 µs avg, 239 µs to 1.095 ms max
Lock Time (s) : 14.460071 s total, 1.259 ms avg, 53 µs to 2.462555 s max  (41.38%)
  95% of Lock : 806.43 ms total, 74 µs avg, 53 µs to 137 µs max
Rows sent     : 1 avg, 0 to 9 max  (0.99%)
Rows examined : 6 avg, 1 to 28 max  (0.15%)

最も遅いクエリのほとんどは、上記の注文テーブルに関係しています。私はMyISAMをストレージエンジンとして使用しているため、考えられる問題は次のとおりです。

  1. テーブルのロック
  2. インデックスの問題

これらの統計をどのように改善できるでしょうか。これらのテーブルに適切なインデックスを設定し、読み取りクエリを改善するためにそれらを微調整し続けました。

テーブルスキーマ

`orderid` int(11) NOT NULL AUTO_INCREMENT,
`cityid` tinyint(3) unsigned NOT NULL DEFAULT '1',
 `model_type` tinyint(1) unsigned DEFAULT '1',
`userid` int(11) DEFAULT NULL,
`usertype` char(1) DEFAULT NULL,
`time` time DEFAULT NULL,
`ordercode` char(8) DEFAULT NULL,
`restid` smallint(3) unsigned NOT NULL,
`areaid` smallint(3) unsigned DEFAULT NULL,
`restname` varchar(50) DEFAULT NULL,
`date` date NOT NULL,
`del_time` time NOT NULL,
`status` tinyint(3) unsigned NOT NULL,
`amount` float NOT NULL,
`deliverycharge` smallint(4) unsigned DEFAULT '0',
`tax` float NOT NULL,
`total` float NOT NULL,
`extras` varchar(255) DEFAULT NULL,
`requests` varchar(255) DEFAULT NULL,
`discount` float DEFAULT NULL,
`rdiscount` float DEFAULT NULL,
`reason` varchar(255) DEFAULT NULL,
`rest_order` tinyint(1) unsigned DEFAULT NULL,
`admin_user` varchar(25) DEFAULT NULL,
`mode` char(1) NOT NULL,
`priority_order` tinyint(1) unsigned DEFAULT '0',
`payment_mode` tinyint(1) unsigned DEFAULT '0',
`km` tinyint(3) unsigned DEFAULT NULL,
`order_type` tinyint(1) NOT NULL DEFAULT '1',
`coupon_discount` smallint(3) DEFAULT '0',
`pickup_time` time NOT NULL,
PRIMARY KEY (`orderid`),
KEY `cityid` (`cityid`),
KEY `date_3` (`date`,`status`,`mode`),
KEY `orderid` (`orderid`),
KEY `time` (`time`),
KEY `userid` (`userid`,`usertype`),
KEY `restid` (`restid`,`date`,`status`)

遅いログクエリ

SELECT `a`.`orderid`, `a`.`date`, `a`.`status`, `a`.`restname`, `a`.`admin_user`, `a`.`model_type`, `b`.`name` as cityname
FROM `tk_order_queue` AS a
INNER JOIN `tk_cities` AS b ON `a`.`cityid` = `b`.`id`
WHERE `a`.`date` =  '2012-06-30'
AND `a`.`status` =  0
AND `a`.`mode` =  1
ORDER BY `a`.`orderid` desc;

それを実行SHOW CREATE TABLE orders\Gして質問に投稿してください
RolandoMySQLDBA

2
それを間違って読んでいますか、それとも平均クエリ時間は1.7ミリ秒ですか?なぜあなたはそれをスピードアップすることを望みますか?
フィロ2012

それがスロークエリログに表示される理由について少し混乱しています。
シェルドン2012

@RolandoMySQLDBAスキーマを添付しました
シェルドン、2012

1
テーブルにインデックスがあるからといって、クエリに適切なインデックスであるとは限りません。遅いクエリのいくつかの例とそのEXPLAIN出力を投稿できますか?また、注文テーブルはどのくらいの頻度で更新されますか?
bobwienholt 2012

回答:


8

すべてのクエリのWHERE句とGROUP BYおよびORDER BYステートメントを比較して、現在のインデックスがEXPLAINプランでそれらをサポートできることを確認する必要があります。

昨日、私はこの質問に答えました:InnoDBとMyISAMと多くのインデックス

その質問で、私もMyISAMテーブルにあなたができるような何かをすることを提案しました

ALTER TABLE orders ROW_FORMAT=Fixed;

これはすべてのVARCHARをCHARとして扱います。すべての行が正確に同じ長さになります。これにより、ディスク容量が80%〜100%増加します。テーブルは、行レイアウトの最大サイズに行数を掛けたものに膨らみます。テーブルのサイズは2倍または3倍になります。

メリットはどこですか?MyISAMテーブルは、他に何も変更せずに、20%から30%高速に読み書きされます。

MySQLデータベースの設計とチューニングの 72、73ページからそのことを学びました。

私は過去にこれについて書きました:


詳細な説明のおかげで、はい、テーブルに追加されたインデックスは、システムで使用されているselect、group by、order byステートメントに使用されるクエリに基づいています。インデックスログなしでクエリを監視し、それに応じてテーブルを更新しています。
シェルドン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.