對不起,很長的帖子！

我有一個包含~30個表(InnoDB引擎)的數(shù)據(jù)庫.這些表中只有兩個,即“事務(wù)”和“移位”非常大(第一個有150萬行,移位有23k行).現(xiàn)在一切正常,我沒有當(dāng)前數(shù)據(jù)庫大小的問題.

但是,我們將擁有一個類似的數(shù)據(jù)庫(相同的數(shù)據(jù)類型,設(shè)計,…),但更大,例如,“交易”表將有大約10億條記錄(每天約2,300萬筆交易),我們正在思考如何我們應(yīng)該在MySQL中處理這么大量的數(shù)據(jù)？ (這是讀寫密集型).我閱讀了很多相關(guān)帖子,看看Mysql(更具體地說是InnoDB引擎)是否可以與數(shù)十億條記錄表現(xiàn)良好,但我仍然有一些問題.我讀過的一些相關(guān)帖子如下：

> Can MySQL reasonably perform queries on billions of rows?
> Is InnoDB (MySQL 5.5.8) the right choice for multi-billion rows?
> Best data store for billions of rows
> How big can a MySQL database get before performance starts to degrade
> Why MySQL could be slow with large tables?
> Can Mysql handle tables which will hold about 300 million records?

到目前為止我已經(jīng)理解為提高非常大的表的性能：

>(對于innoDB表,這是我的情況)增加innodb_buffer_pool_size(例如,高達(dá)80％的RAM).
另外,我發(fā)現(xiàn)了一些其他MySQL性能調(diào)整設(shè)置here in
percona blog
>在表上有適當(dāng)?shù)乃饕?在查詢中使用EXPLAN)
>分區(qū)表
> MySQL Sharding或群集

這是我的問題/困惑：

>關(guān)于分區(qū),我懷疑是否應(yīng)該使用它.一方面,許多人建議在桌子非常大時提高性能.另一方面,我閱讀了許多帖子,說它不會提高查詢性能,也不會使查詢運(yùn)行得更快(例如,here和here).另外,我在MySQL Reference Manual讀到InnoDB外鍵和MySQL分區(qū)不兼容(我們有外鍵).
>關(guān)于索引,現(xiàn)在它們表現(xiàn)良好,但據(jù)我所知,對于非常大的表索引更具限制性(正如Kevin Bedell在他的回答here中提到的).此外,索引加速讀取,同時減慢寫入(插入/更新).那么,對于我們將擁有這個大型數(shù)據(jù)庫的新類似項目,我們應(yīng)該首先插入/加載所有數(shù)據(jù)然后創(chuàng)建索引嗎？ (加快插入速度)
>如果我們不能對我們的大表(“事務(wù)”表)使用分區(qū),那么提高性能的另一種選擇是什么？ (除了MySQl變量設(shè)置,例如innodb_buffer_pool_size).我們應(yīng)該使用Mysql集群嗎？ (我們也有很多連接)

編輯

這是名為“transaction”的最大表的show create table語句：

  CREATE TABLE `transaction` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `terminal_transaction_id` int(11) NOT NULL,
 `fuel_terminal_id` int(11) NOT NULL,
 `fuel_terminal_serial` int(11) NOT NULL,
 `xboard_id` int(11) NOT NULL,
 `gas_station_id` int(11) NOT NULL,
 `operator_id` text NOT NULL,
 `shift_id` int(11) NOT NULL,
 `xboard_total_counter` int(11) NOT NULL,
 `fuel_type` int(11) NOT NULL,
 `start_fuel_time` int(11) NOT NULL,
 `end_fuel_time` int(11) DEFAULT NULL,
 `preset_amount` int(11) NOT NULL,
 `actual_amount` int(11) DEFAULT NULL,
 `fuel_cost` int(11) DEFAULT NULL,
 `payment_cost` int(11) DEFAULT NULL,
 `purchase_type` int(11) NOT NULL,
 `payment_ref_id` text,
 `unit_fuel_price` int(11) NOT NULL,
 `fuel_status_id` int(11) DEFAULT NULL,
 `fuel_mode_id` int(11) NOT NULL,
 `payment_result` int(11) NOT NULL,
 `card_pan` text,
 `state` int(11) DEFAULT NULL,
 `totalizer` int(11) NOT NULL DEFAULT '0',
 `shift_start_time` int(11) DEFAULT NULL,
 PRIMARY KEY (`id`),
 UNIQUE KEY `terminal_transaction_id` (`terminal_transaction_id`,`fuel_terminal_id`,`start_fuel_time`) USING BTREE,
 KEY `start_fuel_time_idx` (`start_fuel_time`),
 KEY `fuel_terminal_idx` (`fuel_terminal_id`),
 KEY `xboard_idx` (`xboard_id`),
 KEY `gas_station_id` (`gas_station_id`) USING BTREE,
 KEY `purchase_type` (`purchase_type`) USING BTREE,
 KEY `shift_start_time` (`shift_start_time`) USING BTREE,
 KEY `fuel_type` (`fuel_type`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1665335 DEFAULT CHARSET=utf8 ROW_FORMAT=COMPACT

謝謝你的時間,

解決方法:

> MySQL可以合理地對數(shù)十億行執(zhí)行查詢嗎？ – MySQL可以“處理”數(shù)十億行. “合理”取決于查詢;讓我們看看他們.
> InnoDB(MySQL 5.5.8)是數(shù)十億行的正確選擇嗎？ – 5.7有一些改進(jìn),但5.5是相當(dāng)不錯的,盡管已經(jīng)將近6 8歲,并且即將不再受到支持.
>數(shù)十億行的最佳數(shù)據(jù)存儲 – 如果您的意思是“引擎”,那么InnoDB.
>在性能開始降低之前,MySQL數(shù)據(jù)庫有多大 – 再次,這取決于查詢.我可以告訴你一個會崩潰的1K行表;我曾與數(shù)十億行表一起工作.
>為什么MySQL可能會因大表而變慢？ – 范圍掃描導(dǎo)致I / O,這是緩慢的部分.
> Mysql可以處理將容納約3億條記錄的表嗎？ – 再次,是的.限制大約是一萬億行.
>(對于innoDB表,這是我的情況)增加innodb_buffer_pool_size(例如,高達(dá)80％的RAM).此外,我在percona博客中找到了一些其他MySQL性能調(diào)整設(shè)置 – 是的
>在表上有適當(dāng)?shù)乃饕?在查詢中使用EXPLAN) – 好吧,讓我們看看它們.在這個關(guān)鍵領(lǐng)域可以犯很多錯誤.
>分區(qū)表 – “分區(qū)不是靈丹妙藥！”我在my blog上豎起了這個
> MySQL Sharding – 目前這是DIY
> MySQL集群 – 目前最好的答案是一些基于Galera的選項(PXC,MariaDB 10,DIY w / Oracle). Oracle的“組復(fù)制”是一個可行的競爭者.
>分區(qū)不支持FOREIGN KEY或“全局”UNIQUE.
> UUID,就你所說的規(guī)模而言,不僅會減慢系統(tǒng)速度,還會實際殺死它. Type 1 UUIDs可能是一種解決方法.
>插入和索引構(gòu)建速度 – 提供單個答案的變化太多.讓我們看看您的暫定CREATE TABLE以及您打算如何提供數(shù)據(jù).
>很多連接 – “規(guī)范化,但不要過度規(guī)范化”.特別是,不要標(biāo)準(zhǔn)化日期時間或浮點(diǎn)數(shù)或其他“連續(xù)”值.
>建立summary tables
>每天2,300萬筆交易 – 如果是2.3M插入(30 /秒),則沒有太大的性能問題.如果更復(fù)雜,則可能需要RAID,SSD,批處理等.
>處理這樣的數(shù)據(jù)量 – 如果大多數(shù)活動都是“最近”行,那么buffer_pool將很好地“緩存”活動,從而避免I / O.如果活動是“隨機(jī)”,則MySQL(或其他任何人)將遇到I / O問題.
>縮小數(shù)據(jù)類型有助于像您這樣的表格.我懷疑你是否需要4個字節(jié)來指定fuel_type.有多個1字節(jié)方法.