架構設計

表結構設計

索引

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设计与开发的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。