建立資料庫
create
database
ifnot
exists
`permission`
default
character
set utf8 default
collate utf8_bin;
create_by varchar(30) not
null comment '建立人',
create_date datetime not
null comment '建立日期',
update_by varchar(30) not
null comment '修改人',
update_date datetime not
null comment '修改日期'
最為常見的隱式型別轉換常見於時間型別與字串型別之間,建議所有時間型別欄位均以時間型別傳入,或者以字串傳入然後通過字串轉換時間函式進行轉換, 如下:
select * from member where gmt_create = str_to_date('20090101 01:02:03','%y%m%d %h:%i:%s');··不要使用select *
原因：
1. mysql中orderby排序時有兩種演算法：一是先查詢select後面的字段然後對其進行排序，二是先查詢需要排序的字段然後排序，再回表中查詢其他字段，相當於查詢兩次，增加了磁碟io數量
如果select 後面字段總長度超過1024位元組（引數max_length_sort_data的預設值）或者查詢字段包括blob或者text大文字欄位時，都會觸發第二種排序演算法，這樣會增加記憶體使用，磁碟io的讀取速度，消耗更多的io
2.join 語句使用 select * 可能導致只需要訪問索引即可完成的查詢需要回表取數，所以禁止使用
資料庫設計：
1.完整性
2.效能
資料庫拆分：
定義：指根據某種特定條件，將存放在乙個資料庫的資料分散到多個資料庫上，減少單個資料庫服務壓力負載。
方式：
垂直切分：根據模組劃分不同的模組表進行切分，即將表切分到其他資料庫上
優點：
資料庫表的切分簡單明瞭，切分規則明確；
應用程式模組清晰明確，整合容易；
資料維護方便易行，容易定位；
缺點：
部分表關聯無法在資料庫級別完成，需要在程式中進行；
對於訪問極其頻繁且資料量超大的表仍然存在效能瓶頸，不一定能滿足要求；
事務處理相對複雜；
切分達到一定程度之後，擴充套件性會受到限制；
過度切分可能會導致系統過於複雜而難以維護；
水平切分：根據表中的邏輯關係，將同乙個表中資料按照某種切分規則切分到其他資料庫上或者表中
eg：按照資料範圍：1-100萬資料，100萬到200萬資料進行切分；按照年限進行切分；按照地點切分；按照計算公式，id主鍵進行被2取模,（蜂巢拆庫）
表關聯基本能夠在資料庫端全部完成；
不會存在某些超大型資料量和高負載的表遇到瓶頸的問題；
應用程式端整體架構改動相對較少；
事務處理相對簡單；
只要切分規則能夠定義好，擴充套件性一般不會受到限制；
缺點：
切分規則相對複雜，很難抽象出乙個能滿足整個資料庫的切分規則；
後期的維護難度有所增加，人為手工定位資料較困難。
應用系統各模組耦合度非常高，可能會對後面資料的遷移切分造成一定的困難。
若切分不合理，會造成資料表的冷熱不均現象。
資料庫注意事項
主要就是6點 1.必須考慮業務唯一性並建復合唯一索引 2.所有字段盡量設定為not null 3.區分度低的字段不要建索引 4.邏輯外來鍵要建索引 5.用uuiddelete id varchar 32 not null default 做偽刪除 6.建議確定無負數的字段設定unsigned 建表時...
資料庫注意事項
索引會佔據瓷盤空間，資料越大索引佔據空間越大 mysql表中除了聚集索引外其他索引都是輔助索引 secondary index，也稱為非聚集索引 與聚集索引的區別是 輔助索引的葉子節點不包含行記錄的全部資料。聚焦索引 更適合between and和order by操作，每個表只能建立乙個聚焦索引 如...
MySQL資料庫建表注意事項
1.庫名 表名 欄位名必須使用小寫字母，分割。原因 mysql在linux下資料庫名 表名 列名 別名大小寫規則是這樣的 1 資料庫名與表名是嚴格區分大小寫的 2 表的別名是嚴格區分大小寫的 3 列名與列的別名在所有的情況下均是忽略大小寫的 4 變數名也是嚴格區分大小寫的 mysql在windows...