分割槽表方案：
根據實際業務需要，盡量做到均衡的將資料分開。
-- 分割槽表 建表語句
create table `detail_temp` (
`detail_uuid` bigint(20) not null auto_increment,
`detail_status` tinyint(4) not null default '10' comment '10ok11del',
`detail_ctime` timestamp not null default '0000-00-00 00:00:00',
`detail_mtime` timestamp not null default current_timestamp,
`create_time` date default '0000-00-00' comment '分割槽時間',
primary key (` detail_uuid`,create_time)
) engine=innodb default charset=utf8
partition by range (year(create_time))
(partition p_2018 values less than (2018) engine = innodb,
partition p_2019 values less than (2019) engine = innodb,
partition p_2020 values less than (2020) engine = innodb,
partition p_others values less than maxvalue engine = innodb);
首先給`detail` 新加乙個分割槽時間字段， `create_time` date default '0000-00-00' comment '分割槽時間',
-- 匯入資料
insert into detail_temp select * from detail;
-- 更新 create_time 字段
update `detail_temp` set `create_time` = date(` detail_ctime`) where 1=1;
explain
select * from detail_temp where create_time >='2015-11-19' and create_time <='2019-11-19';
explain
select * from detail_temp where create_time ='2015-11-19' ;
-- 建立分割槽索引 校驗 分割槽索引的使用情況
-- q1 1486 按照時間進行分割槽，不能使用timestamp 型別，因為以時間進行分割槽，會涉及時區問題，因此部分mysql版本不一致 修正方案：新增`create_time`欄位date型別
-- q2 1503 分割槽字段必須是建立的表的主鍵，因為分割槽表的主鍵，如果主鍵不一致就會帶來查詢的一系列問題 修正方案：primary key (` detail_uuid`,create_time)
mysql分表分庫實現 MySql分表分庫思路
一.資料庫瓶頸 1.1io瓶頸 第一種 磁碟讀io瓶頸，熱點資料太多，資料庫快取放不下，每次查詢時會產生大量的io 分庫和垂直分表 第二種 網路io瓶頸，請求的資料太多，網路頻寬不夠 分庫 1.2cpu瓶頸 第一種 sql問題，如sql中包含join，group by，order by，非索引字段條...
MySQL範圍分表分庫 mysql 分表分庫策略
唯一id的生成 下面列舉幾種常見的唯一id生成方案，需要滿足兩大核心需求 1.全域性唯一 2趨勢有序 1.用資料庫的auto increment 自增id 來生成，每次通過寫入資料庫一條記錄，利用資料庫id自增的特性獲取唯一，有序的id。優點 使用資料庫原有的功能，相對簡單 能夠保證唯一 能夠保證遞...
mysql 分庫分表實戰 MySQL分庫分表實戰
為什麼要分庫分表 在大型 中，當使用者量以及使用者產生的業務資料量達到單庫單錶效能極限時，為了支撐業務可持續發展，對於重要的核心業務必然要進行分庫分表來儲存業務資料。對於非核心業務產生的大量資料，例如爬蟲爬取的資訊，論壇產生的資料等，可以考慮把資料儲存在像mongodb這樣的nosql儲存裡面，這些...