一些
mysql 的
優化經驗
從資料庫結構做起
字段型別的定義時遵循以下規則:
選用字段長度最小 優先使用定長型 盡可能的定義 "not null" 數值型字段中避免使用 "zerofill" 如果要儲存的資料為字串, 且可能值已知且有限, 優先使用 enum 或 set 索引的優化至關重要(以下如果沒有特殊說明, 均指查詢密集的情況)
被索引的字段的長度越小, 該索引的效率越高 被索引的字段中, 值的重複越少, 該索引的效率越高 查詢語句中, 如果使用了 "group" 子句, 根據其中字段出現的先後順序建立多欄位索引 查詢語句中, 如果使用了 "distinct", 根據其中字段出現的先後順序建立多欄位索引 "where" 子句中, 出現對同一表中多個不同欄位的 "and" 條件時, 按照字段出現的先後順序建立多欄位索引 "where" 子句中, 出現對同一表中多個不同欄位的 "or" 條件時, 對重複值最少的字段建立單字段索引 進行 "內/外連線" 查詢時, 對 "連線字段" 建立索引 對 "主鍵" 的 "unique" 索引 毫無意義, 不要使用 被索引字段盡可能的使用 "not null" 屬性 對寫入密集型表, 儘量減少索引, 尤其是 "多欄位索引" 和 "unique" 索引 查詢語句的優化
多多利用 "explain" 查詢索引使用情況, 以便找出最佳的查詢語句寫法和索引設定方案 慎用 "select *", 查詢時只選出必須字段 查詢使用索引時, 所遍歷的索引條數越少, 索引字段長度越小, 查詢效率越高 (可使用 "explain" 查詢索引使用情況) 避免使用
mysql 函式對查詢結果進行處理, 將這些處理交給客戶端程式負責 使用 "limit" 時候, 盡量使 "limit" 出的部分位於整個結果集的前部, 這樣的查詢速度更快, 系統資源開銷更低 在 "where" 子句中使用多個欄位的 "and" 條件時, 各個字段出現的先後順序要與多字段索引中的順序相符 在 "where" 子句 中使用 "like" 時, 只有當萬用字元不出現在條件的最左端時才會使用索引 在
mysql 4.1 以上版本中, 避免使用子查詢, 盡量使用 "內/外連線" 實現此功能 減少函式的使用, 如果可能的話, 盡量用單純的表示式來代替 避免在 "where" 子句中, 對不同字段進行 "or" 條件查詢, 將其拆分成多個單一欄位的查詢語句效率更高
附: mysql 字段長度說明表
mysql 字段長度說明 tinyint 1 位元組 **allint 2 位元組 mediumint 3 位元組 integer: 4 位元組 bigint 8 位元組 double 8 位元組 float(x) x <=24: 4 位元組
x > 24: 8 位元組 decimal(m,d) m=d: m 位元組 date 3 位元組 datetime 8 位元組 timestamp 4 位元組 time 4 位元組 year 1 位元組 char(m) m 位元組 varchar(m) 值長度 + 1 位元組 tinyblob 值長度 + 1 位元組 tinytext 值長度 + 1 位元組 blob 值長度 + 2 位元組 text 值長度 + 2 位元組 mediumblob 值長度 + 3 位元組 mediumtext 值長度 + 3 位元組 longblob 值長度 + 4 位元組 longtext 值長度 + 4 位元組 enum 1 或 2 位元組
取決於列舉值數
mysql的一些優化
前言 sql優化，是一種概率層面的優化。至於是否實際使用了我們的優化，需要通過explain進行推測。注意 服務層中有sql優化器，可能會影響我們的優化,同時註明 sql的優化前提是有索引 有索引 有索引 in和exists的使用場景 select from a where exists selec...
UGUI的一些效能優化經驗
自從unity問世以來，ui一直都存在比較大的問題，自帶的ongui不能所見即所得，製作過程比較麻煩。於是出現了很多第三方的優秀的ui外掛程式，比如很多專案裡面用到的ngui，或者後來出的fairygui。unity官方在4.x時代開始推出了自己的新ui系統，名為ugui。由於是官方出品，所以選擇使...
AND一些經驗
目錄 一 參考 1 程式設計師2020工作規範范文 總結 good 適合多看，程式設計師每天 每月做的事情總結了 一 目的 1 在公司來了很久了，有時候一些經驗想把記錄下來，專案 做人 等等 一 專案 1 板卡 pci2012a分為支援和不支援音效卡的 一 做人 1 不要過度依賴別人 1 有問題立馬...