建表時,如何讓mysql標(biāo)識列ID從1開始自動增長

在列侯面加identity（1,1）

專注于為中小企業(yè)提供成都網(wǎng)站設(shè)計、做網(wǎng)站服務(wù),電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)本溪免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上1000家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴充和轉(zhuǎn)變。

例如

create table a

(

a int identity(1,1),

name varchar(50)

)

高性能MySQL：選擇標(biāo)識符（identifier）

選擇標(biāo)識符（identifier）

為標(biāo)識列（identifier column）選擇合適的數(shù)據(jù)類型非常重要 一般來說更有可能用標(biāo)識列與其他值進行比較（例如 在關(guān)聯(lián)操作中） 或者通過標(biāo)識列尋找其他列 標(biāo)識列也可能在另外的表中作為外鍵使用 所以為標(biāo)識列選擇數(shù)據(jù)類型時 應(yīng)該選擇跟關(guān)聯(lián)表中的對應(yīng)列一樣的類型（正如我們在本章早些時候所論述的一樣 在相關(guān)的表中使用相同的數(shù)據(jù)類型是個好主意 因為這些列很可能在關(guān)聯(lián)中使用）

當(dāng)選擇標(biāo)識列的類型時 不僅僅需要考慮存儲類型 還需要考慮MySQL 對這種類型怎么執(zhí)行計算和比較 例如 MySQL 在內(nèi)部使用整數(shù)存儲ENUM 和SET 類型 然后在做比較操作時轉(zhuǎn)換為字符串

一旦選定了一種類型 要確保在所有關(guān)聯(lián)表中都使用同樣的類型 類型之間需要精確匹配 包括像UNSIGNED 這樣的屬性注 混用不同數(shù)據(jù)類型可能導(dǎo)致性能問題 即使沒有性能影響 在比較操作時隱式類型轉(zhuǎn)換也可能導(dǎo)致很難發(fā)現(xiàn)的錯誤 這種錯誤可能會很久以后才突然出現(xiàn) 那時候可能都已經(jīng)忘記是在比較不同的數(shù)據(jù)類型

在可以滿足值的范圍的需求 并且預(yù)留未來增長空間的前提下 應(yīng)該選擇最小的數(shù)據(jù)類型 例如有一個state_id 列存儲美國各州的名字注 就不需要幾千或幾百萬個值 所以不需要使用INT TINYINT 足夠存儲 而且比INT 少了 個字節(jié) 如果用這個值作為其他表的外鍵 個字節(jié)可能導(dǎo)致很大的性能差異 下面是一些小技巧 整數(shù)類型

整數(shù)通常是標(biāo)識列最好的選擇 因為它們很快并且可以使用AUTO_INCREMENT

ENUM 和SET 類型

對于標(biāo)識列來說 EMUM 和SET 類型通常是一個糟糕的選擇 盡管對某些只包含固定狀態(tài)或者類型的靜態(tài) 定義表 來說可能是沒有問題的 ENUM 和SET 列適合存儲固定信息 例如有序的狀態(tài) 產(chǎn)品類型 人的性別

舉個例子 如果使用枚舉字段來定義產(chǎn)品類型 也許會設(shè)計一張以這個枚舉字段為主鍵的查找表（可以在查找表中增加一些列來保存描述性質(zhì)的文本 這樣就能夠生成一個術(shù)語表 或者為網(wǎng)站的下拉菜單提供有意義的標(biāo)簽） 這時 使用枚舉類型作為標(biāo)識列是可行的 但是大部分情況下都要避免這么做

字符串類型如果可能 應(yīng)該避免使用字符串類型作為標(biāo)識列 因為它們很消耗空間 并且通常比數(shù)字類型慢 尤其是在MyISAM 表里使用字符串作為標(biāo)識列時要特別小心

MyISAM 默認對字符串使用壓縮索引 這會導(dǎo)致查詢慢得多 在我們的測試中 我們注意到最多有 倍的性能下降

對于完全 隨機 的字符串也需要多加注意 例如MD （） SHA （） 或者UUID（） 產(chǎn)生的字符串 這些函數(shù)生成的新值會任意分布在很大的空間內(nèi) 這會導(dǎo)致INSERT 以及一些SELECT 語句變得很慢注 :

因為插y 入值會隨機地寫到索引的不同位置 所以使得INSERT語句更慢 這會導(dǎo)致頁分裂 磁盤隨機訪問 以及對于聚簇存儲引擎產(chǎn)生聚簇索引碎片 關(guān)于這一點第 章有更多的討論

SELECT語句會變得更慢 因為邏輯上相鄰的行會分布在磁盤和內(nèi)存的不同地方

隨機值導(dǎo)致緩存對所有類型的查詢語句效果都很差 因為會使得緩存賴以工作的訪問局部性原理失效 如果整個數(shù)據(jù)集都一樣的 熱 那么緩存任何一部分特定數(shù)據(jù)到內(nèi)存都沒有好處 如果工作集比內(nèi)存大 緩存將會有很多刷新和不命中

如果存儲UUID 值 則應(yīng)該移除 符號 或者更好的做法是 用UNHEX（） 函數(shù)轉(zhuǎn)換UUID 值為 字節(jié)的數(shù)字 并且存儲在一個BINARY（ ） 列中 檢索時可以通過HEX（）函數(shù)來格式化為十六進制格式

UUID（） 生成的值與加密散列函數(shù)例如SHA （） 生成的值有不同的特征 UUID 值雖然分布也不均勻 但還是有一定順序的 盡管如此 但還是不如遞增的整數(shù)好用

當(dāng)心自動生成的schema

我們已經(jīng)介紹了大部分重要數(shù)據(jù)類型的考慮（有些會嚴重影響性能 有些則影響較?。?但是我們還沒有提到自動生成的schema 設(shè)計有多么糟糕

寫得很爛的schema 遷移程序 或者自動生成schema 的程序 都會導(dǎo)致嚴重的性能問題 有些程序存儲任何東西都會使用很大的VARCHAR 列 或者對需要在關(guān)聯(lián)時比較的列使用不同的數(shù)據(jù)類型 如果schema 是自動生成的 一定要反復(fù)檢查確認沒有問題

對象關(guān)系映射（ORM）系統(tǒng)（以及使用它們的 框架 ）是另一種常見的性能噩夢 一些ORM 系統(tǒng)會存儲任意類型的數(shù)據(jù)到任意類型的后端數(shù)據(jù)存儲中 這通常意味著其沒有設(shè)計使用更優(yōu)的數(shù)據(jù)類型來存儲 有時會為每個對象的每個屬性使用單獨的行 甚至使用基于時間戳的版本控制 導(dǎo)致單個屬性會有多個版本存在

這種設(shè)計對開發(fā)者很有吸引力 因為這使得他們可以用面向?qū)ο蟮姆绞焦ぷ?不需要考慮數(shù)據(jù)是怎么存儲的 然而 對開發(fā)者隱藏復(fù)雜性 的應(yīng)用通常不能很好地擴展 我們建議在用性能交換開發(fā)人員的效率之前仔細考慮 并且總是在真實大小的數(shù)據(jù)集上做測試 這樣就不會太晚才發(fā)現(xiàn)性能問題

返回目錄 高性能MySQL

編輯推薦

ASP NET MVC 框架揭秘

Oracle索引技術(shù)

ASP NET開發(fā)培訓(xùn)視頻教程

lishixinzhi/Article/program/MySQL/201311/29682

怎么使用navicat for mysql 定義標(biāo)識列

你是想改表結(jié)構(gòu)還是插入數(shù)據(jù)？

表結(jié)構(gòu)：右鍵點中表，選設(shè)計表，移動到最底部一條，“創(chuàng)建欄位”將在這之后增加一列；“插入欄位”將在這列之前增加一列。

插入數(shù)據(jù)：雙擊打開表，下面有個“+”的符號，點一下，增加一條記錄，然后再點一下下面的對鉤保存數(shù)據(jù)。

navicat 很簡單的。慢慢熟悉吧，記得去把它漢化哦。

mysql數(shù)據(jù)庫如何創(chuàng)建自增長標(biāo)識？ id int identity(1,1)在mysql中行不同啊?。?！

使用auto_increment修飾要自增的列。實例：create table stu

(stuid int auto_increment primary key,

stuname varchar(20)) 追問這個我之前就試過了，要手動插入id值，如果不插入就報錯。

----------------------------------------------------

你插入的語句是什么。上面的表能實現(xiàn)自增id