show index from table_name ## 檢視該錶的索引資訊table 索引所在表名
non_unique ：非唯一的索引，可以看到primary_key是0，因為必須是唯一的
key_name ：索引的名字
seq_in_index ：索引中該列的位置，針對聯合索引比較直觀
column_name ：索引列的名稱
collation ：列以什麼方式儲存，可以是a或null，b+樹索引總是a，即排序的；如果是使用的heap儲存引擎，並且建立了hash索引，這會顯示為null
cardinality ：非常關鍵的值，標識索引中唯一值的數目的估計值，cardinality/表的記錄數應盡可能的接近1，如果非常小,那使用者需要考慮是否還有必要建立這個索引。故在訪問高選擇性屬性的字段並從表中取出很少一部分資料時，對於字段新增b+樹索引是非常有必要的
sub_part ：是否是列的部分被索引
packed：關鍵字是否被壓縮
null ：是否索引中含有null值
index_type：索引的型別，innodb儲存引擎只支援b+樹索引，所以都顯示btree
comment：注釋
cardinality 值非常重要，優化器會根據這個值來判斷是否使用這個索引，但是這個值並不是實時更新的，即並非索引的更新都會更新該值，因為代價太大，只是乙個大概值
在innodb儲存引擎中，cardinality統計資訊的更新發生在兩個操作中：insert和update。innodb儲存引擎內部對更新cardinality資訊的策略為:
表中1/16的資料已發生了改變
stat_modified_counter>2000 000 000
第一種策略為自從上次統計cardinality資訊後，表中的1/16的資料已經發生過變化，這是需要更新cardinality資訊
第二種情況考慮的是，如果對錶中某一行資料頻繁地進行更新操作，這時表中的資料實際並沒有增加，實際發生變化的還是這一行資料，則第一種更新策略就無法適用這種情況，故在innodb儲存引擎內部有乙個計數器start_modified_counter,
用來表示發生變化的 次數,當start_modified_counter>2 000 000 000 時，則同樣更新cardinality資訊
SQL 判斷要新增列的表中是否有主鍵
if exists select 1 from sysobjects where parent obj object id tb and xtype pk begin print 表中已經有主鍵,列只能做為普通列新增 新增int型別的列,預設值為0 alter table tb add 列名 int...
mysql欄位是否存在 mysql判斷列是否存在
本篇文章將通過儲存過程來判斷列 字段 是否存在。請看詳情。判斷字段是否存在 drop procedure if exists schema change delimiter create procedure schema change begin declare currentdatabase va...
MySQL 分割槽欄位列是否有必要再單獨建索引
對於分割槽字段必須是主鍵的一部分，那麼建了復合主鍵之後，是否需要對分許字段再單獨新增乙個索引呢？有沒有效果？下面來驗證一下 create table effect new id bigint 20 not null auto increment,type tinyint 4 not null def...