怎么查看mysql數(shù)據(jù)庫中的表是否損壞

可以使用語句檢查表。如果結(jié)果的msg_text部分是好的，那么你的表是健康的。反之，則表明mysql數(shù)據(jù)庫中的表有損壞。另外有些厲害的高手一額可以通過運(yùn)行腳本來檢測。

創(chuàng)新互聯(lián)是一家專業(yè)的成都網(wǎng)站建設(shè)公司，我們專注成都網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作、網(wǎng)絡(luò)營銷、企業(yè)網(wǎng)站建設(shè)，買友情鏈接，1元廣告為企業(yè)客戶提供一站式建站解決方案，能帶給客戶新的互聯(lián)網(wǎng)理念。從網(wǎng)站結(jié)構(gòu)的規(guī)劃UI設(shè)計(jì)到用戶體驗(yàn)提高，創(chuàng)新互聯(lián)力求做到盡善盡美。

MyISAM?表可以采用以下方法進(jìn)行修復(fù)?：使用?reapair table?或myisamchk?來修復(fù)。如果修復(fù)無效，采用備份恢復(fù)表。

階段1?：檢查你的表

如果你有很多時(shí)間，運(yùn)行myisamchk *.MYI?或myisamchk -e *.MYI?。使用-s?（沉默）選項(xiàng)禁止不必要的信息。如果mysqld?服務(wù)器處于宕機(jī)狀態(tài)，應(yīng)使用--update-state?選項(xiàng)來告訴myisamchk?將表標(biāo)記為'?檢查過的'?。

你必須只修復(fù)那些myisamchk?報(bào)告有錯(cuò)誤的表。對這樣的表，繼續(xù)到階段2?。如果在檢查時(shí)，你得到奇怪的錯(cuò)誤(?例如out of memory?錯(cuò)誤)?，或如果myisamchk?崩潰，到階段3?。

階段2?：簡單安全的修復(fù)

注釋：如果想更快地進(jìn)行修復(fù)，當(dāng)運(yùn)行myisamchk?時(shí)，你應(yīng)將sort_buffer_size?和Key_buffer_size?變量的值設(shè)置為可用內(nèi)存的大約25%?。

首先，試試myisamchk -r -q tbl_name(-r -q?意味著“?快速恢復(fù)模式”)?。這將試圖不接觸數(shù)據(jù)文件來修復(fù)索引文件。如果數(shù)據(jù)文件包含它應(yīng)有的一切內(nèi)容和指向數(shù)據(jù)文件內(nèi)正確地點(diǎn)的刪除連接，這應(yīng)該管用并且表可被修復(fù)。開始修復(fù)下一張表。否則，執(zhí)行下列過程：

在繼續(xù)前對數(shù)據(jù)文件進(jìn)行備份。使用myisamchk -r tbl_name(-r?意味著“?恢復(fù)模式”)?。這將從數(shù)據(jù)文件中刪除不正確的記錄和已被刪除的記錄并重建索引文件。

如果前面的步驟失敗，使用myisamchk --safe-recover tbl_name?。安全恢復(fù)模式使用一個(gè)老的恢復(fù)方法，處理常規(guī)恢復(fù)模式不行的少數(shù)情況(?但是更慢)?。如果在修復(fù)時(shí)，你得到奇怪的錯(cuò)誤(?例如out of memory?錯(cuò)誤)?，或如果myisamchk?崩潰，到階段3?。

階段3?：困難的修復(fù)

只有在索引文件的第一個(gè)16K?塊被破壞，或包含不正確的信息，或如果索引文件丟失，你才應(yīng)該到這個(gè)階段。在這種情況下，需要?jiǎng)?chuàng)建一個(gè)新的索引文件。按如下步驟操做：

把數(shù)據(jù)文件移到安全的地方。使用表描述文件創(chuàng)建新的(?空)?數(shù)據(jù)文件和索引文件：

shell mysql db_name

mysql SET AUTOCOMMIT=1;

mysql TRUNCATE TABLE tbl_name;

mysql quit

如果你的MySQL?版本沒有TRUNCATE TABLE?，則使用DELETE FROM tbl_name?。將老的數(shù)據(jù)文件拷貝到新創(chuàng)建的數(shù)據(jù)文件之中?；氐诫A段2?。現(xiàn)在myisamchk -r -q?應(yīng)該工作了。你還可以使用REPAIR TABLE tbl_name USE_FRM?，將自動(dòng)執(zhí)行整個(gè)程序。

階段4?：非常困難的修復(fù)

只有.frm?描述文件也破壞了，你才應(yīng)該到達(dá)這個(gè)階段。這應(yīng)該從未發(fā)生過，因?yàn)樵诒肀粍?chuàng)建以后，描述文件就不再改變了。

從一個(gè)備份恢復(fù)描述文件然后回到階段3?。你也可以恢復(fù)索引文件然后回到階段2?。對后者，你應(yīng)該用myisamchk -r?啟動(dòng)。

如果你沒有進(jìn)行備份但是確切地知道表是怎樣創(chuàng)建的，在另一個(gè)數(shù)據(jù)庫中創(chuàng)建表的一個(gè)拷貝。刪除新的數(shù)據(jù)文件，然后從其他數(shù)據(jù)庫將描述文件和索引文件移到破壞的數(shù)據(jù)庫中。這樣提供了新的描述和索引文件，但是讓.MYD?數(shù)據(jù)文件獨(dú)自留下來了?；氐诫A段2并且嘗試重建索引文件。

Mysql表分區(qū)狀態(tài)查詢

一、查詢mysql表是否為分區(qū)表：可以查看表具有哪幾個(gè)分區(qū)、分區(qū)的方法、分區(qū)中數(shù)據(jù)的記錄數(shù)等信息

SELECT PARTITION_NAME,PARTITION_METHOD,PARTITION_EXPRESSION,PARTITION_DESCRIPTION,TABLE_ROWS,SUBPARTITION_NAME,SUBPARTITION_METHOD,SUBPARTITION_EXPRESSION

FROM information_schema.PARTITIONS WHERE TABLE_SCHEMA=SCHEMA() AND TABLE_NAME='xw_coobill_order';

二、查詢表有多少個(gè)分區(qū)

SELECT TABLE_NAME, COUNT(*) AS CNT

FROM information_schema.PARTITIONS WHERE PARTITION_NAME IS NOT NULL

GROUP BY TABLE_NAME ORDER BY CNT DESC LIMIT 50;

三、分析執(zhí)行語句

explain partitions select * from range_datetime where hiredate = '20151207124503' and hiredate='20151210111230';

四、分區(qū)管理

常規(guī)HASH和線性HASH的增加收縮分區(qū)的原理是一樣的。增加和收縮分區(qū)后原來的數(shù)據(jù)會根據(jù)現(xiàn)有的分區(qū)數(shù)量重新分布。HASH分區(qū)不能刪除分區(qū)，所以不能使用DROP PARTITION操作進(jìn)行分區(qū)刪除操作；

只能通過ALTER TABLE ... COALESCE PARTITION num來合并分區(qū)，這里的num是減去的分區(qū)數(shù)量；

可以通過ALTER TABLE ... ADD PARTITION PARTITIONS num來增加分區(qū)，這里是null是在原先基礎(chǔ)上再增加的分區(qū)數(shù)量。

如何清理mysql數(shù)據(jù)庫緩存數(shù)據(jù)？

1、打開mysql的客戶端 這里使用navicat，連接數(shù)據(jù)庫，等到navicat主頁面，雙擊需要操作的數(shù)據(jù)庫連接。

2、登錄到數(shù)據(jù)庫主頁面后，點(diǎn)擊左側(cè)的數(shù)據(jù)庫連接，打開數(shù)據(jù)庫，可以看到可以操作的所有數(shù)據(jù)庫。

3、這時(shí)有有兩個(gè)數(shù)據(jù)庫，目標(biāo)是將數(shù)據(jù)1的所有數(shù)據(jù)同步到數(shù)據(jù)庫2上，需要點(diǎn)擊主頁面上的。

4、打開工具菜單，選擇數(shù)據(jù)庫同步菜單，彈出數(shù)據(jù)同步的對話框，可以選擇數(shù)據(jù)源，目標(biāo)數(shù)據(jù)庫。

5、選擇數(shù)據(jù)庫源和需要操作的數(shù)據(jù)庫后，然后在選擇目標(biāo)數(shù)據(jù)庫連接，目標(biāo)數(shù)據(jù)庫，然后在選擇需要操作的表，點(diǎn)擊開始即可。

php怎么顯示mysql數(shù)據(jù)庫的碎片？

MySQL 8.0.16 已經(jīng)發(fā)布，它像往常一樣增強(qiáng)了組復(fù)制 Group Replication 功能。

這篇文章介紹了 MySQL 8.0.16 為 Group Replication 帶來的新功能：

Message fragmentation（信息碎片化）。

背景

Group Replication 目前使用 XCom（一種組通信引擎），特點(diǎn)：原子性，組員狀態(tài)檢測等。每個(gè)成員的組復(fù)制插件先將信息轉(zhuǎn)發(fā)到本地 XCom，再由 XCom 最終以相同的順序?qū)⑿畔鬟f給每個(gè)組成員的 Group Replication 插件。

XCom 由單線程實(shí)現(xiàn)。當(dāng)一些成員廣播信息過大時(shí)，XCom 線程必須花費(fèi)更多的時(shí)間來處理那個(gè)大信息。如果成員的 XCom 線程忙于處理大信息的時(shí)間過長，它可能會去查看其他成員的 XCom 實(shí)例。例如，忙碌的成員失效。如果是這樣，該組可以從該組中驅(qū)逐忙碌的成員。

MySQL 8.0.13 新增??group_replication_member_expel_timeout??系統(tǒng)變量，您可以通過它來調(diào)整將成員從組中驅(qū)逐的時(shí)間。例如，懷疑成員失敗，但成員實(shí)際上忙于處理大信息，給成員足夠的時(shí)間來完成處理。在這種情況下，是否為成員增加驅(qū)逐超時(shí)的設(shè)置是一種權(quán)衡。有可能等了很久，該成員實(shí)際真的失效了。

Message fragmentation（信息碎片化）

MySQL 8.0.16 的 Group Replication 插件新增用來處理大信息的功能：信息碎片化。

簡而言之，您可以為成員的廣播信息指定最大值。超過最大值的信息將分段為較小的塊傳播。

您可以使用? group_replication_communication_max_message_size??系統(tǒng)變量指定允許的信息最大值（默認(rèn)值為10 MiB）。

示例

讓我們用一個(gè)例子來解釋新功能。圖1顯示了當(dāng)綠色成員向組廣播信息時(shí)，新功能是如何處理的。

圖1 對傳出信息進(jìn)行分段

1. 如果信息大小超過用戶允許的最大值（group_replication_communication_max_message_size），則該成員會將信息分段為不超過最大值的塊。

2. 該成員將每個(gè)塊廣播到該組，即將每個(gè)塊單獨(dú)轉(zhuǎn)發(fā)到XCom。

XCom 最終將這些塊提供給組成員。下面三張圖展示出了中間綠色成員發(fā)送大信息時(shí)工作的新特征。

圖2a 重新組合傳入的信息：第一個(gè)片段

3. 成員得出結(jié)論，傳入的信息實(shí)際上是一個(gè)更大信息的片段。

4. 成員緩沖傳入的片段，因?yàn)樗麄冋J(rèn)為片段是仍然不完整的信息的一部分。（片段包含必要的元數(shù)據(jù)以達(dá)到這個(gè)結(jié)論。）

圖2b 重新組合傳入的信息：第二個(gè)片段

5. 見上面的第3步。

6. 見上面的第4步。

圖2c 重新組合傳入的信息：最后一個(gè)片段

7. 成員得出結(jié)論，傳入的信息實(shí)際上是一個(gè)更大信息的片段。

8. 成員得出結(jié)論，傳入的片段是最后一個(gè)缺失的塊，重新組合原始信息，然后對其進(jìn)行處理，傳輸完畢。

結(jié)論

MySQL 8.0.16 已經(jīng)發(fā)布后，組復(fù)制現(xiàn)在可以確保組內(nèi)交換的信息大小不超過用戶定義的閾值。這可以防止組內(nèi)誤判而驅(qū)逐成員。