架構設計
表結構設計
索引sql語句
1.表結構設計的核心思想是什麼？
容量評估，效能優化，硬體公升級，垂直拆分，水平拆分
2.有個大表為了乙個查詢(一天就查2次)，領導要你建索引(索引空間大小有500g)，
你怎麼考慮，是建還是不建？建索引時要考慮哪些因素？
3.執行計畫中有 filesort 就會進行磁碟檔案排序嗎(詳細說明)?
using filesort：當我們的query 中包含order by 操作，而且無法利用索引完成排序操
作的時候，mysql query optimizer 不得不選擇相應的排序演算法來實現。
資料庫的正規化：
1nf)：資料庫表中的字段都是單一屬性的，不可再分，這個單一屬性由基本型別構成，包括整型、實數、字元型、邏輯型、日期型等
2nf)：資料庫表中不存在非關鍵字段 對任一候選關鍵字段 的部分 函式依賴
選課關係表為selectcourse(學號, 姓名, 年齡, 課程名稱, 成績, 學分)
(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)
3nf)：在第二正規化的基礎上，資料表中如果不存在非關鍵字段 對任一候選關鍵字段 的傳遞 函式依賴 則符合第三正規化。
所謂傳遞函式依賴，指的是如 果存在"a → b → c"的決定關係，則c傳遞函式依賴於a
學生關係表為student(學號, 姓名, 年齡, 所在學院, 學院地點, 學院**)，關鍵字為單一關鍵字"學號"
(學號) → (所在學院) → (學院地點, 學院**)即存在非關鍵字段"學院地點"、"學院**"對關鍵字段"學號"的傳遞函式依賴
在商業環境中，絕大多數超越第3正規化的設計都是不切實際的。 由正規化的高階來看，越高等級的正規化所產生的表越多，
而在應用程式使用的過程中越多的表join和查詢造成的效能損耗的問題，甚至很多情況下為了兼顧效能和開發我們甚至要做一下反正規化的操作
1 表字段型別選擇
tinyint,int,bigint
decimal(m,n)
datetime,timestamp
varcahr(n)
utf8
表容量評估，資料歸檔評估
架構設計
讀寫分離，schema解耦，冷熱資料分表
表結構設計：innodb,auto increment primary key,comment
原則：只增不減，自增主鍵，主鍵不應該被修改，不用字串做主鍵，拆開寬表
varchar(500),控制單錶資料量，越短越好
控制列數量
表字段數少而精
io高效、全表遍歷、表修復快、 提高併發、 alter table快
單錶多少字段合適？
單錶1g體積500w行評估
順序讀1g檔案需要n秒
單行不超過200byte
單錶不超50個純int欄位
單錶不超20個char(10)個字段
單表字段數上限控制在20-50個
update_time timestamp not null default current_timestamp on update current_timestamp
default 0，不使用default null
default ''
不使用text，blob
索引字段定義not null
禁用外來鍵
數字型vs字元型索引：更高效、查詢更快、占用空間更小
示例：mysql> create table yhq_t11(id int unsigned);
mysql> insert into yhq_t11 values (inet_aton('127.0.0.1'));
mysql> select * from yhq_t11;
| id |
| 2130706433 |
mysql> select inet_ntoa(id) from yhq_t11;
| inet_ntoa(id) |
儲存精確浮點數必須使用decimal替代float和double
盡可能不要使用text、 blob
1) 索引排序問題，只能使用max_sort_length的長度或者手工指定order by substring(column,
length)的長度來排序
2) memory引擘不支援text,blog型別，會在磁碟上生成臨時表
3) 可能浪費更多的空間
4) 可能無法使用adaptive hash index
5) 導致使用where沒有索引的語句變慢
6) varchar的效能會比text高很多
為什麼不要default null
索引不會包括null值。影響索引的統計資訊，影響優化器的判斷。
復合索引中只要有一列含有null值，那麼這一列對於此復合索引就是無效的， null欄位很難查詢優化
(null欄位無法索引) 。
a)如果null欄位被索引，需要額外的1位元組作為判斷是否為null的標誌位「需要mysql內部進行特殊處理)
b)使索引，索引統計，值的比較變得更複雜
c)可用0，」 代替
d)如果是索引字段，一定要定義為not null
不在資料庫裡存
索引1.唯一鍵不和主鍵重複。
2.不要修改聚焦索引。
3.使用explain判斷sql語句是否合理使用索引，盡量避免extra列出現： using file sort， usingtemporary。
4.索引不是越多越好，盡量合併索引，合理建立聯合索引(避免冗餘)。
5.合理利用覆蓋索引,結合核心sql優先考慮覆蓋索引。
6.不要修改聚集索引(主鍵)
7.不要給選擇性低的字段建單列索引， mysql對索引的過濾性有要求，如果過濾性太低， mysql會放棄使用
例如：不要給「性別」列建立索引。
8.不要使用外來鍵約束
9.字元型別字段盡量使用字首索引， 太長的索引不僅影響寫入效能，而且使用效能也差
10.能不加的索引盡量不要加
綜合評估資料密度和資料分布
最好不超過字段數20%
sql語句
慎用count(*)
count(*)的資源開銷大，盡量不用少用！
實時統計：用memcache,雙向更新，零晨跑基準
非實時統計：盡量用單獨統計表，定期重算
select /*+first_rows(1)*/ count(*) from t1 where rownum<2;
比如，有些應用，只是想看看我表裡是否有資料，或者滿足某個條件的，是否有資料。
用first_rows來作。
sql語句盡可能簡單
拒絕大sql,拆解成多條簡單sql
減少鎖時間
用上更多cpu
簡單sql快取命中率更高
insert語句使用batch提交
降低cup,不在資料庫做運算
select id*16 from yhq_t1;
上面的語句放在mysql不起眼，不是很明顯，這些運算沒必要放在資料庫裡，資料庫盡量做到簡
單，資料庫就檢索資料，對這些資料的加工就放在應用層。
讓資料庫多做她擅長的事：
1)盡量不在資料庫做運算
2)複雜運算移動程式端cpu
3)盡可能簡單應用mysql
必須使用繫結變數, 避免常量的直接引用
頻繁的硬解析會影響資料庫效能
ibatis中，所有的 ##都是繫結變數
mysql設計表月份 mysql,表設計
閒著沒事搞了一下，歡迎指教。使用者表 create table usr uid int 11 not null,name char 10 default null,primary key uid engine innodb default charset utf8 吃飯記錄表 create tabl...
mysql表的設計 mysql,表設計
閒著沒事搞了一下，歡迎指教。使用者表 create table usr uid int 11 not null,name char 10 default null,primary key uid engine innodb default charset utf8 吃飯記錄表 create tabl...
mysql索引設計 MySQL索引設計原則
一 mysql常用的索引型別 1.1主鍵索引 primary key 1.2唯一索引 unique 1.3普通索引 index 1.4全文索引 1.5組合索引 二 mysql常用的資料結構 2.1b tree 2.2雜湊索引 三 索引的設計原則 3.1選擇唯一性索引 被設為唯一性的值可以設定為索引，...