可以看mysql的data文件夾下面的數(shù)據(jù)庫文件，就可以查看當(dāng)前分區(qū)情況。還有幾種獲取MySQL分區(qū)表信息的常用方法SHOW CREATE TABLE 可以查看創(chuàng)建分區(qū)表的CREATE語句 SHOW TABLE STATUS 可以查看表是否為分區(qū)表 查看INFORMATION_SCHEMA.PARTITIONS表 可以查看表具有哪幾個(gè)分區(qū)、分區(qū)的方法、分區(qū)中數(shù)據(jù)的記錄數(shù)等重要信息
10年積累的做網(wǎng)站、成都做網(wǎng)站經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有沿灘免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。
給你個(gè)簡單的演示
$sql="SELECT * FROM `數(shù)據(jù)表` WHERE `xx = 'xx'";
$pd=mysql_query($sql,$con);
$con是數(shù)據(jù)庫連接配置
select為數(shù)據(jù)查詢，刪除用del 添加用insert 修改用update
mysql分庫分表一般有如下場景
其中1，2相對(duì)較容易實(shí)現(xiàn),本文重點(diǎn)講講水平拆表和水平拆庫,以及基于mybatis插件方式實(shí)現(xiàn)水平拆分方案落地。
在 《聊一聊擴(kuò)展字段設(shè)計(jì)》 一文中有講解到基于KV水平存儲(chǔ)擴(kuò)展字段方案,這就是非常典型的可以水平分表的場景。主表和kv表是一對(duì)N關(guān)系,隨著主表數(shù)據(jù)量增長,KV表最大N倍線性增長。
這里我們以分KV表水平拆分為場景
對(duì)于kv擴(kuò)展字段查詢,只會(huì)根據(jù)id + key 或者 id 為條件的方式查詢,所以這里我們可以按照id 分片即可
分512張表(實(shí)際場景具體分多少表還得根據(jù)字段增加的頻次而定)
分表后表名為kv_000 ~ kv_511
id % 512 = 1 .... 分到 kv_001,
id % 512 = 2 .... 分到 kv_002
依次類推!
水平分表相對(duì)比較容易,后面會(huì)講到基于mybatis插件實(shí)現(xiàn)方案
場景:以下我們基于博客文章表分庫場景來分析
目標(biāo):
表結(jié)構(gòu)如下(節(jié)選部分字段):
按照user_id sharding
假如分1024個(gè)庫,按照user_id % 1024 hash
user_id % 1024 = 1 分到db_001庫
user_id % 1024 = 2 分到db_002庫
依次類推
目前是2個(gè)節(jié)點(diǎn),假如后期達(dá)到瓶頸,我們可以增加至4個(gè)節(jié)點(diǎn)
最多可以增加只1024個(gè)節(jié)點(diǎn),性能線性增長
對(duì)于水平分表/分庫后,非shardingKey查詢首先得考慮到
基于mybatis分庫分表,一般常用的一種是基于spring AOP方式, 另外一種基于mybatis插件。其實(shí)兩種方式思路差不多。
為了比較直觀解決這個(gè)問題,我分別在Executor 和StatementHandler階段2個(gè)攔截器
實(shí)現(xiàn)動(dòng)態(tài)數(shù)據(jù)源獲取接口
測試結(jié)果如下
由此可知,我們需要在Executor階段 切換數(shù)據(jù)源
對(duì)于分庫:
原始sql:
目標(biāo)sql:
其中定義了三個(gè)注解
@useMaster 是否強(qiáng)制讀主
@shardingBy 分片標(biāo)識(shí)
@DB 定義邏輯表名 庫名以及分片策略
1)編寫entity
Insert
select
以上順利實(shí)現(xiàn)mysql分庫,同樣的道理實(shí)現(xiàn)同時(shí)分庫分表也很容易實(shí)現(xiàn)。
此插件具體實(shí)現(xiàn)方案已開源:
目錄如下:
mysql分庫分表,首先得找到瓶頸在哪里(IO or CPU),是分庫還是分表,分多少？不能為了分庫分表而拆分。
原則上是盡量先垂直拆分 后 水平拆分。
以上基于mybatis插件分庫分表是一種實(shí)現(xiàn)思路,還有很多不完善的地方,
例如:
1.按時(shí)間分表
這種分表方式有一定的局限性，當(dāng)數(shù)據(jù)有較強(qiáng)的實(shí)效性，如微博發(fā)送記錄、微信消息記錄等，這種數(shù)據(jù)很少有用戶會(huì)查詢幾個(gè)月前的數(shù)據(jù)，如就可以按月分表。
2.按區(qū)間范圍分表
一般在有嚴(yán)格的自增id需求上，如按照user_id水平分表：
table_1 ?user_id從1~100w?
table_2 ?user_id從101~200w?
table_3 ?user_id從201~300w?
...?
3.hash分表
通過一個(gè)原始目標(biāo)的ID或者名稱通過一定的hash算法計(jì)算出數(shù)據(jù)存儲(chǔ)表的表名，然后訪問相應(yīng)的表。
按如下分10張表：
function?get_hash_table($table,?$userid)
{
$str?=?crc32($userid);
if?($str??0)?{
$hash?=?"0"?.?substr(abs($str),?0,?1);
}?else?{
$hash?=?substr($str,?0,?2);
}
return?$table?.?"_"?.?$hash;
}
echo get_hash_table('message',?'user18991');?//結(jié)果為message_10
echo get_hash_table('message',?'user34523');?//結(jié)果為message_13
1,接收到sql;2,把sql放到排隊(duì)隊(duì)列中 ;3,執(zhí)行sql;4,返回執(zhí)行結(jié)果。在這個(gè)執(zhí)行過程中最花時(shí)間在什么地方呢？第一，是排隊(duì)等待的時(shí)間，第二，sql的執(zhí)行時(shí)間。其實(shí)這二個(gè)是一回事，等待的同時(shí)，肯定有sql在執(zhí)行。所以我們要縮短sql的執(zhí)行時(shí)間。
mysql中有一種機(jī)制是表鎖定和行鎖定，為什么要出現(xiàn)這種機(jī)制，是為了保證數(shù)據(jù)的完整 性，我舉個(gè)例子來說吧，如果有二個(gè)sql都要修改同一張表的同一條數(shù)據(jù)，這個(gè)時(shí)候怎么辦呢，是不是二個(gè)sql都可以同時(shí)修改這條數(shù)據(jù)呢？很顯然mysql 對(duì)這種情況的處理是，一種是表鎖定（myisam存儲(chǔ)引擎），一個(gè)是行鎖定（innodb存儲(chǔ)引擎）。表鎖定表示你們都不能對(duì)這張表進(jìn)行操作，必須等我對(duì) 表操作完才行。行鎖定也一樣，別的sql必須等我對(duì)這條數(shù)據(jù)操作完了，才能對(duì)這條數(shù)據(jù)進(jìn)行操作。如果數(shù)據(jù)太多，一次執(zhí)行的時(shí)間太長，等待的時(shí)間就越長，這 也是我們?yōu)槭裁匆直淼脑颉?/p>
mysql數(shù)據(jù)庫對(duì)1億條數(shù)據(jù)的分表方法設(shè)計(jì)：
目前針對(duì)海量數(shù)據(jù)的優(yōu)化有兩種方法：
（1）垂直分割
優(yōu)勢(shì)：降低高并發(fā)情況下，對(duì)于表的鎖定。
不足：對(duì)于單表來說，隨著數(shù)據(jù)庫的記錄增多，讀寫壓力將進(jìn)一步增大。
（2）水平分割
如果單表的IO壓力大，可以考慮用水平分割，其原理就是通過hash算法，將一張表分為N多頁，并通過一個(gè)新的表（總表），記錄著每個(gè)頁的的位置。
假如一個(gè)門戶網(wǎng)站，它的數(shù)據(jù)庫表已經(jīng)達(dá)到了1億條記錄，那么此時(shí)如果通過select去查詢，必定會(huì)效率低下（不做索引的前提下）。為了降低單表的讀寫IO壓力，通過水平分割，將這個(gè)表分成10個(gè)頁，同時(shí)生成一個(gè)總表，記錄各個(gè)頁的信息，那么假如我查詢一條id=100的記錄，它不再需要全表掃描，而是通過總表找到該記錄在哪個(gè)對(duì)應(yīng)的頁上，然后再去相應(yīng)的頁做檢索，這樣就降低了IO壓力。
重慶分公司
重慶分公司
