推薦：mysql數(shù)據(jù)庫(kù)索引損壞及修復(fù)經(jīng)驗(yàn)分享
這篇文章主要介紹了mysql數(shù)據(jù)庫(kù)索引損壞及修復(fù)經(jīng)驗(yàn)分享,需要的朋友可以參考下 mysql表索引被破壞的問題及解決 下午上班，驚聞我的dedecms的網(wǎng)站出問題了，訪問一看，果然全屏報(bào)錯(cuò)，檢查mysql日志，錯(cuò)誤信息為： Table '.\dedecmsv4\dede_archives' is marked as crashe

 　　這篇文章主要介紹了在MySQL中使用Sphinx實(shí)現(xiàn)多線程搜索的方法,修改Sphinx的搜索引擎配置即可,需要的朋友可以參考下

　　MySQL、Sphinx及許多數(shù)據(jù)庫(kù)與搜索引擎中的查詢是單線程的。比如說(shuō)，在一臺(tái)32個(gè)CPU核心、16個(gè)磁盤的R910服務(wù)器上執(zhí)行一個(gè)查詢，它最多只會(huì)用到一個(gè)核心與一個(gè)磁盤。沒錯(cuò)，只會(huì)使用一個(gè)。

　　如果查詢是CPU密集型作業(yè)，那么會(huì)使用大約3%的整機(jī)CPU能力(以上述32核機(jī)器為例)。如果是磁盤密集型，則大約會(huì)使用6%的整機(jī)IO能力(也是和上例同樣的配置，16個(gè)磁盤組成RAID10或RAID0)。

　　我再換個(gè)說(shuō)法吧。如果你在一臺(tái)單核單磁盤的機(jī)器上執(zhí)行了某個(gè)查詢，花了10秒，那么把同樣的查詢放到一臺(tái)32核16磁盤的機(jī)器上去跑，同樣需要10秒，不會(huì)有絲毫改善。

　　你早就知道這一點(diǎn)了，對(duì)吧?那么，我的問題是——有沒有辦法可以改善呢?

　　如果是Sphinx，太棒了，答案是有!而且不需要花上太多的工夫。你甚至不需要修改應(yīng)用與數(shù)據(jù)庫(kù)，只需要稍微改下Sphinx的配置。

　　計(jì)劃

　　首先，我來(lái)說(shuō)明一下我們的目標(biāo)。

　　Sphinx本身就支持分布式搜索，在很久以前就已經(jīng)朝著水平擴(kuò)展的目標(biāo)來(lái)設(shè)計(jì)。如果索引在一臺(tái)機(jī)器上放不下，可以讓多臺(tái)機(jī)器分別對(duì)區(qū)別的部分進(jìn)行索引，設(shè)置一個(gè)聚合節(jié)點(diǎn)，負(fù)責(zé)從應(yīng)用接收請(qǐng)求，然后把請(qǐng)求再同時(shí)發(fā)給所有的數(shù)據(jù)節(jié)點(diǎn)，最后將它們返回的結(jié)果合并起來(lái)，返回給應(yīng)用。在應(yīng)用看起來(lái)，就好像只有一臺(tái)服務(wù)器在為它服務(wù)。

　　好，下面你猜如何著?哈，我們可以把這個(gè)功能應(yīng)用到單臺(tái)機(jī)器上，讓我們的查詢快上n多倍。而且，現(xiàn)在Sphinx已經(jīng)支持這種做法了，所以我們根本不用再假裝查詢哪些遠(yuǎn)程節(jié)點(diǎn)。

　　還有另外一個(gè)好處，配置分布式搜索以后，索引是可以并行建的!

　　還是有一點(diǎn)需要注意，雖然這種做法可以加速絕大多數(shù)的查詢，但還是有一些例外的情況。因?yàn)�，并行的查詢結(jié)果仍然需要合并起來(lái)，而這個(gè)合并過(guò)程是單線程的。而且，合并包括一些CPU密集的操作，如分級(jí)、排序，甚至用GROUP BY進(jìn)行COUNT，如果數(shù)據(jù)量很大，合并過(guò)程就會(huì)變成瓶頸。

　　要確認(rèn)這一點(diǎn)也很簡(jiǎn)單，只要查看Sphinx的查詢?nèi)罩�，看看每個(gè)查詢匹配的記錄數(shù)有多少，我們就心里有數(shù)了。

　　執(zhí)行

　　假設(shè)在服務(wù)器上一個(gè)索引配置如下 (很多細(xì)節(jié)都省略了):

　　 代碼如下:

　　source src1

　　{

　　type = mysql

　　sql_query = SELECT id, text FROM table

　　}

　　index idx1

　　{

　　type = plain

　　source = src1

　　}

　　searchd

　　{

　　dist_threads = 0 # default

　　}

　　現(xiàn)在我們使用有3個(gè)CPU核心與磁盤的機(jī)器來(lái)做這個(gè)索引--就是這個(gè)idx1.下面是我們更改的配置文件 :

　　代碼如下:

　　source src1

　　{

　　type = mysql

　　sql_query = SELECT id, text FROM table

　　}

　　source src1p0 : src1

　　{

　　sql_query = SELECT id, text FROM table WHERE id % 3 = 0;

　　}

　　source src1p1 : src1

　　{

　　sql_query = SELECT id, text FROM table WHERE id % 3 = 1;

　　}

　　source src1p2 : src1

　　{

　　sql_query = SELECT id, text FROM table WHERE id % 3 = 2;

　　}

　　index idx1_template

　　{

　　type = plain

　　source = src1

　　}

　　index idx1p0 : idx1_template

　　{

　　source = src0

　　}

　　index idx1p1 : idx1_template

　　{

　　source = src1

　　}

　　index idx1p2 : idx1_template

　　{

　　source = src2

　　}

　　index idx1

　　{

　　type = distributed

　　local = idx1p0

　　local = idx1p1

　　local = idx1p2

　　}

　　searchd

　　{

　　dist_threads = 3

　　}

　　做完這些后，你需要重建索引. 但是現(xiàn)在idx1p0到idx1p2的索引indexer命令可以同步進(jìn)行.

　　另外，用區(qū)別的操作來(lái)分離數(shù)據(jù)不是最好的辦法, 你可以在MYSQL中用一個(gè)輔助表來(lái)區(qū)分它們的范圍, 配合 sql_query_range使用或是別的什么, 具體根據(jù)你的數(shù)據(jù)來(lái)決定.

　　寫在最后

　　我一直都很喜歡 Sphinx，Sphinx可以如此容易的擴(kuò)展到你所需要的足夠多的機(jī)器上，并且這種方式在很多年前就已經(jīng)在被使用了。然后，我想，我并沒有與我往常一樣，利用這個(gè)特性來(lái)使得在一臺(tái)機(jī)器上的查詢變得更快。嗯，這并不是在說(shuō)它很慢或者其實(shí)什么，只是，查詢永遠(yuǎn)不會(huì)太快，不是嗎?

分享：Windows Server 2003 下配置 MySQL 集群(Cluster)教程
這篇文章主要介紹了Windows Server 2003 下配置 MySQL 集群(Cluster)教程,本文先是講解了原理知識(shí),然后給出詳細(xì)配置步驟和操作方法,需要的朋友可以參考下 MySQL 群集是 MySQL 適合于分布式計(jì)算環(huán)境的高可用、高冗余版本。它采用了 NDB Cluster 存儲(chǔ)引擎，允許在 1 個(gè)群