設計表是我們開發過程中必然要涉及到的步驟，想要乙個優秀的系統，表的設計是基礎，要是基礎沒設計好，那什麼sql語句優化，索引優化，都是杯水車薪設計表我們一般從2個角度觸發考慮問題： 正規化設計思想 / 物理設計正規化設計的三個標準：
表的字段只能是單一的屬性
表的主鍵和其他非主鍵，是乙個一對一的關聯關係
表的主鍵和其它非主鍵，是乙個直接的關係
第一正規化例子：
明顯不符合第一正規化要求，name_age包含2個屬性 name 和 age，規範建表-->
第二正規化例子：
學生和課程不是乙個一對一的關係,而是乙個多對多的關係
第三正規化例子：
字段冗餘，關聯的class不僅有name還有teacher_name、plan，假如這門課變更了，需要將這2個字段一起修改，這部分可優化？--->
以上是對三大正規化的乙個基本的演示，但是這樣子會不會有問題呢？1.定義資料庫 、表 、字段 的命名規範：可讀性我們如果想要查詢a同學選了那幾個老師的課程，會使用到多個join語句，當產生笛卡爾積問題的時候，效能就不必多說了，差所以說在設計表不一定嚴格滿足正規化要求，我們的設計優先順序應該是 業務 >= 效能 > 正規化要求
------->在某些場景我們需要使用這種空間換時間的方式，當然在不同的系統以及系統不同的階段情況都會發生變化，這就比較考驗乙個架構師-sql優化 的能力了
大小寫區分情況使用駝峰命名 ， 也可使用橫線分割
表意性使用能表意的詞彙，一般選擇英文（我也試過中文，中文那乙個系統的要全中文不能中間出現其他語言）
長名原則
儘量減少縮寫，保證乙個完整性，間接提高可讀性
2.資料庫儲存引擎選擇：
一般情況(主要工作：增刪改查)下我們從myisam 和 innodb中選擇乙個，結合業務在根據每種引擎的特性進行選擇，引擎特性分析在 mysql - 1. 效能-優化概述 and 架構與儲存引擎 中有具體分析
3. 表中字段的資料型別選擇：
每乙個欄位在型別選擇上都是乙個集合 (當然集合大小是不固定的 1~n , n《系統支援型別數），根據效能的排列，以及字段表意的選擇，簡單的設計了乙個排序規則：
優先 使用空間占用少的型別
數字型別
寫操作和讀操作在效能上都是最好的
日期型別/時間型別
資料的儲存也是數字型別
字元型別
優先選擇varchar可變長度的字元型別，減少空間占用
blob型別
在對於精度要求高的領域：貨幣、金融 等領域 使用decimal字段
float
4 byte
非精準型別
double
8 byte
非精準型別
dicimal
open（每4byte存9個數字，小數點佔1byte）
精準型別
timestamp 與 datetime的區別：
型別大小byte
範圍格式
用途時區影響
datetime
81000-01-01 00:00:00
~ 9999-12-31 23:59:59
yyyy-mm-dd hh:mm:ss
無timestamp
41970-01-01 00:00:00
~2037-12-31 23:59:59
yyyy-mm-dd hh:mm:ss
有set time_zone 設定時區情況 一般為 8:00
mysql5無法注入 mysql5注入
對mysql5注入時，可以直接查詢information schema中的tables表，快速找到所需的表段。同時可以利用group concat函式，得到你想得到的東西，不用limit乙個乙個猜。前面先轉轉別人的東西 and 1 2 union select 1,2,group concat us...
初識MySQL（5）表的聯結
表的聯結就是將兩個不同的表通過他們公共的列屬性合成乙個表，方便我們對其中的屬性進行更進一步的操作，而在表的聯結的過程中就會出現乙個我們之前沒有接觸過的概念 外來鍵。外鍵指的就是b表中的屬性中如果有a表的主鍵屬性，那麼稱這個屬性為b表的外來鍵。現在假設有兩個表，vendors和products表，分別...
MySQL5的異常處理
1.sample problem log of failures 問題樣例 故障記錄 當insert失敗時，我希望能將其記錄在日誌檔案中我們用來展示出錯處理的問題樣例是很普通的。我希望得到錯誤的記錄。當insert失敗時，我想在另乙個檔案中記下這些錯誤的資訊，例如出錯時間，出錯原因等。我對插入特別感...