所有表必須使用 innodb 儲存引擎
沒有特殊要求（即 innodb 無法滿足的功能如：列儲存，儲存空間資料等）的情況下，所有表必須使用 innodb 儲存引擎（mysql 5.5 之前預設使用 myisam，5.6 以後預設的為 innodb）innodb 支援事務，支援行級鎖，更好的恢復性，高併發下效能更好。
資料庫和表的字符集統一使用 utf8
相容性更好，統一字符集可以避免由於字符集轉換產生的亂碼，不同的字符集進行比較前需要進行轉換會造成索引失效。
所有表和字段都需要新增注釋
使用 comment 從句新增表和列的備註 從一開始就進行資料字典的維護。
盡量控制單錶資料量的大小，建議控制在 500 萬以內
500 萬並不是 mysql 資料庫的限制，過大會造成修改表結構、備份、恢復都會有很大的問題，可以用歷史資料歸檔（應用於日誌資料），分庫分表（應用於業務資料）等手段來控制資料量大小。
謹慎使用 mysql 分割槽表
分割槽表在物理上表現為多個檔案，在邏輯上表現為乙個表 謹慎選擇分割槽鍵，跨分割槽查詢效率可能更低 建議採用物理分表的方式管理大資料。
盡量做到冷熱資料分離，減小表的寬度
mysql 限制每個表最多儲存 4096 列，並且每一行資料的大小不能超過 65535 位元組 減少磁碟 io，保證熱資料的記憶體快取命中率（表越寬，把錶裝載進記憶體緩衝池時所占用的記憶體也就越大,也會消耗更多的 io） 更有效的利用快取，避免讀入無用的冷資料 經常一起使用的列放到乙個表中（避免更多的關聯操作）
禁止在表中建立預留字段
預留欄位的命名很難做到見名識義 預留字段無法確認儲存的資料型別，所以無法選擇合適的型別 對預留字段型別的修改，會對錶進行鎖定
禁止在資料庫中儲存，檔案等大的二進位制資料
通常檔案很大，會短時間內造成資料量快速增長，資料庫進行資料庫讀取時，通常會進行大量的隨機 io 操作，檔案很大時，io 操作很耗時 通常儲存於檔案伺服器，資料庫只儲存檔案位址資訊。
禁止從開發環境，測試環境直接連線生成環境資料庫
原因：timestamp 儲存的時間範圍 1970-01-01 00:00:01 ~ 2038-01-19-03:14:07。
timestamp 占用 4 位元組和 int 相同，但比 int 可讀性高，超出 timestamp 取值範圍的使用 datetime 型別儲存。
經常會有人用字串儲存日期型的資料（不正確的做法）：
decimal 型別為精準浮點數，在計算時不會丟失精度。占用空間由定義的寬度決定，每 4 個位元組可以儲存 9 位數字，並且小數點要占用乙個位元組。可用於儲存比 bigint 更大的整型資料。
索引並不是越多越好！索引可以提高效率同樣也可以降低效率；索引可以增加查詢效率，但同樣也會降低插入和更新的效率，甚至有些情況下會降低查詢效率。
因為 mysql 優化器在選擇如何優化查詢時，會根據統一資訊，對每乙個可以用到的索引來進行評估，以生成出乙個最好的執行計畫，如果同時有很多個索引都可以用於查詢，就會增加 mysql 優化器生成執行計畫的時間，同樣會降低查詢效能。
5.6 版本之前，乙個 sql 只能使用到乙個表中的乙個索引，5.6 以後，雖然有了合併索引的優化方式，但是還是遠遠沒有使用乙個聯合索引的查詢方式好
innodb 是一種索引組織表：資料的儲存的邏輯順序和索引的順序是相同的。每個表都可以有多個索引，但是表的儲存順序只能有一種 innodb是按照主鍵索引的順序來組織表的。
不要使用更新頻繁的列作為主鍵，不適用多列主鍵（相當於聯合索引） 不要使用 uuid、md5、hash、字串列作為主鍵（無法保證資料的順序增長）。主鍵建議使用自增 id 值。
建立索引的目的是：希望通過索引進行資料查詢，減少隨機 io，增加查詢效能 ，索引能過濾出越少的資料，則從磁碟中讀入的資料也就越少。
因為這樣會增加查詢優化器生成執行計畫的時間。
對於頻繁的查詢優先考慮使用覆蓋索引。
覆蓋索引：就是包含了所有查詢字段(where,select,ordery by,group by包含的字段)的索引
覆蓋索引的好處：
盡量避免使用外來鍵約束。
預編譯語句可以重複使用這些計畫，減少 sql 編譯所需要的時間，還可以解決動態 sql 所帶來的 sql 注入的問題 只傳引數，比傳遞 sql 語句更高效 相同語句可以一次解析，多次使用，提高處理效率。
隱式轉換會導致索引失效。如：
select name,phone from customer where id = '111';如：
insert into values ('a','b','c');
應使用：
insert into t(c1,c2,c3) values ('a','b','c');
子查詢效能差的原因：
對於 mysql 來說，是存在關聯快取的，快取的大小可以由 join_buffer_size 引數進行設定。
在 mysql 中，對於同乙個 sql 多關聯（join）乙個表，就會多分配乙個關聯快取，如果在乙個 sql 中關聯的表越多，所占用的記憶體也就越大。
如果程式中大量的使用了多表關聯的操作，同時 join_buffer_size 設定的也不合理的情況下，就容易造成伺服器記憶體溢位的情況，就會影響到伺服器資料庫效能的穩定性。
同時對於關聯操作來說，會產生臨時表操作，影響查詢效率 mysql 最多允許關聯 61 個表，建議不超過 5 個。
資料庫更適合處理批量操作 合併多個相同的操作到一起，可以提高處理效率
in 的值不要超過 500 個， in 操作可以更有效的利用索引，or 大多數情況下很少能利用到索引。
會把表中所有符合條件的資料裝載到記憶體中，然後在記憶體中對所有資料根據隨機生成的值進行排序，並且可能會對每一行都生成乙個隨機值，如果滿足條件的資料集非常大，就會消耗大量的 cpu 和 io 及記憶體資源。
推薦在程式中獲取乙個隨機值，然後從資料庫中獲取資料的方式。
對列進行函式轉換或計算時會導致無法使用索引。
不推薦：
where date(create_time)='20190101'
推薦：where create_time >= '20190101' and create_time < '20190102'
pt-online-schema-change 它會首先建立乙個與原表結構相同的新錶，並且在新表上進行表結構的修改，然後再把原表中的資料複製到新錶中，並在原表中增加一些觸發器。
把原表中新增的資料也複製到新錶中，在行所有資料複製完成之後，把新錶命名成原表，並把原來的表刪除掉,把原來乙個 ddl 操作，分解成多個小的批次進行。
當達到最大連線數限制時，還執行 1個 有 super 許可權的使用者連線 super 許可權只能留給 dba 處理問題的賬號使用。
程式使用資料庫賬號只能在乙個 db 下使用，不准跨庫 程式使用的賬號原則上不准有 drop 許可權。
乙份完整的ACSII碼表
雖然現在很多都是有unicode碼了，這也是個趨勢。但與硬體通訊時，比如與數據機通訊時，雖然用的也是ucs2編碼 用於傳送unicode字元 但實際交流還是採用的是ascii碼，ascii碼在內容控制上還是有很大的用去，如命令返回格式 分割等，奉上乙份完整意義的acsii碼，為開發助力。ascii表...
這是乙份完整的Python魔術方法教程
在python中，所有以 雙下劃線包起來的方法，都統稱為 magic method 中文稱 魔術方法 例如類的初始化方法 init python中所有的魔術方法均在官方文件中有相應描述，但是對於官方的描述比較混亂而且組織比較鬆散。很難找到乙個例子。今天我在苦惱魔術方法的時候，發現了乙個好東西，乙份完...
乙份完整的單機版slurm部署
場景使用 一台8卡gpu伺服器，想要多人使用，每次提交任務可以使用一塊卡 也可以使用兩塊，具體需要配置 比如第9個人使用時就要排隊，等前面8個人用完才可以使用gpu做計算，基於這樣的乙個情況，我研究了下slurm，花了兩天時間終於實現了我需要的功能，以下是我所有的部署操作，乙份很完整的單機slurm...