1、tinyint(M), M默認爲4;
SMALLINT(M), M默認爲6;
MEDIUMINT(M), M默認爲9;
INT(M),M默認爲11;
BIGINT(M),M默認爲20.
M表示最大顯示寬度, M寫不寫都是按照默認的長度。
建表若設置了zerofill(0填充)，此時需要自己制定長度，會在數字前面補充0；
2、varchar存儲規則：
4.0版本以下，varchar(20)，指的是20字節，如果存放UTF8漢字時，只能存6個（每個漢字3字節）
5.0版本以上，varchar(20)，指的是20字符，無論存放的是數字、字母還是UTF8漢字（每個漢字3字節），都可以存放20個，最大大小是65532字節
3、decimal(a,b)：a指小數點左邊和右邊之和，b指小數點右邊的位數。
decimal:數字型，128bit，不存在精度損失，常用於銀行帳目計算。（28個有效位）
4、通過客戶端修改timestamp默認值時，會遇到了問題提示無法修改，需要通過腳本或者在建表時進行修改。
alter table ts_role
MODIFY column create_tm timestamp default CURRENT_TIMESTAMP COMMENT ‘創建時間’
5、mysql在建表時的創建、修改時間有什麼用?
表創建時更新創建和修改時間；修改表字段時，修改時間改變；
6、RDS是關係型數據庫服務（Relational Database Service）的簡稱，是一種即開即用、穩定可靠、可彈性伸縮的在線數據庫服務。
7、id爲19位數字，子單號爲15位數字，運單號位12位數字，任務號爲32位小寫字母和數字組合，卡車號爲P+11位數字
8、MySQL中MyISAM與InnoDB區別及選擇
選擇：
因爲MyISAM相對簡單所以在效率上要優於InnoDB.如果系統讀多，寫少。對原子性要求低。那麼MyISAM最好的選擇。且MyISAM恢復速度快。可直接用備份覆蓋恢復。
如果系統讀少，寫多的時候，尤其是併發寫入高的時候。InnoDB就是首選了。
9、mysql字符集 utf8 和utf8mb4 的區別
utf8mb4比utf8多了emoji編碼支持.
如果實際用途上來看,可以給要用到emoji的庫或者說表,設置utf8mb4.
比如評論要支持emoji可以用到.
建議普通表使用utf8 如果這個表需要支持emoji就使用utf8mb4
10、Mysql中的排序規則utf8_unicode_ci、utf8_general_ci的區別
utf8_general_ci 校對速度快，但準確度稍差。
utf8_unicode_ci 準確度高，但校對速度稍慢。
如果你的應用有德語、法語或者俄語，請一定使用utf8_unicode_ci。一般用utf8_general_ci就夠了。
主鍵：用於確定一張表的唯一標識
外鍵：用於與另一張表的關聯。是能確定另一張表記錄的字段，用於保持數據的一致性。
視圖：類似於快照，可以查看複雜的結構，本身是一張虛表，用於做查詢
索引：加快查詢速度，但索引的創建有一定的限速
存儲過程：一些SQL的集合，執行速度快，執行後會存儲到數據庫中
觸發器：用於保證主、外鍵的安全性。
id使用bigint類型，長度設置爲20；
標題使用varchar類型，長度100；
圖片使用varchar類型，長度300；
富文本編輯器使用text類型，長度默認；
狀態使用tinyint，長度1；
創建和修改時間使用datetime，長度默認；
爲什麼數據庫主鍵不要自增，而要用UUID這個類？
UUID.randomUUID().toString()是JDK自身提供的自動生成主鍵的方法，由16位字符組成，全局唯一，
並且可以防止注入式攻擊：刪除時通過id會在url中暴露該id，使用UUID後可以隱藏起來不暴露給用戶。
缺點在於生成的結果串過長，另外影響innodb，所有使用B樹索引的數據都會受到影響。
使用自增會有如下缺點：如果A表用自增（id）作爲主鍵，B表關聯A表表時，
是通過A表的Id作爲關聯的，假如我不小心把A表的
記錄刪除了，重新追加記錄，這是Id變了，還要更
新B表，那多麻煩啊！！