MySQL主鍵設計

時間  2019-12-12
標籤 mysql 設計 欄目 MySQL 简体版
原文   原文鏈接

目錄html

在項目過程當中遇到一個看似極爲基礎的問題，可是在深刻思考後仍是引出了很多問題，以爲有必要把這一學習過程進行記錄。mysql

MySQL主鍵設計原則

  • MySQL主鍵應當是對用戶沒有意義的。
  • MySQL主鍵應該是單列的，以便提升鏈接和篩選操做的效率
  • 永遠也不要更新MySQL主鍵
  • MySQL主鍵不該包含動態變化的數據，如時間戳、建立時間列、修改時間列等
  • MySQL主鍵應當有計算機自動生成。

主鍵設計的經常使用方案

自增ID

優勢：spring

一、數據庫自動編號，速度快，並且是增量增加，彙集型主鍵按順序存放，對於檢索很是有利。sql

二、 數字型，佔用空間小，易排序，在程序中傳遞方便。數據庫

缺點：
一、不支持水平分片架構，水平分片的設計當中，這種方法顯然不能保證全局惟一。
二、表鎖緩存

在MySQL5.1.22以前，InnoDB自增值是經過其自己的自增加計數器來獲取值，該實現方式是經過表鎖機制來完成的（AUTO-INC LOCKING）。鎖不是在每次事務完成後釋放，而是在完成對自增加值插入的SQL語句後釋放，要等待其釋放才能進行後續操做。好比說當表裏有一個auto_increment字段的時候，innoDB會在內存裏保存一個計數器用來記錄auto_increment的值，當插入一個新行數據時，就會用一個表鎖來鎖住這個計數器，直到插入結束。若是大量的併發插入，表鎖會引發SQL堵塞。
在5.1.22以後，InnoDB爲了解決自增主鍵鎖表的問題，引入了參數innodb_autoinc_lock_mode：安全

  • 0：經過表鎖的方式進行，也就是全部類型的insert都用AUTO-inc locking（表鎖機制）。
  • 1：默認值，對於simple insert 自增加值的產生使用互斥量對內存中的計數器進行累加操做，對於bulk insert 則仍是使用表鎖的方式進行。
  • 2：對全部的insert-like 自增加值的產生使用互斥量機制完成，性能最高，併發插入可能致使自增值不連續，可能會致使Statement 的 Replication 出現不一致，使用該模式，須要用 Row Replication的模式。

三、自增主鍵不連續服務器

Create Table: CREATE TABLE `tmp_auto_inc` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `talkid` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=gbk
1 row in set (0.00 sec)

當插入10條記錄的時候，由於AUTO_INCREMENT=16，因此下次再插入的時候，主鍵就會不連續。架構

UUID

優勢
一、全局惟一性、安全性、可移植性。併發

二、可以保證獨立性，程序能夠在不一樣的數據庫間遷移，效果不受影響。

三、保證生成的ID不只是表獨立的，並且是庫獨立的，在你切分數據庫的時候尤其重要

缺點
一、針對InnoDB引擎會徒增IO壓力，InnoDB爲彙集主鍵類型的引擎，數據會按照主鍵進行排序，因爲UUID的無序性，InnoDB會產生巨大的IO壓力。InnoDB主鍵索引和數據存儲位置相關（簇類索引），uuid 主鍵可能會引發數據位置頻繁變更，嚴重影響性能。
二、UUID長度過長，一個UUID佔用128個比特（16個字節）。主鍵索引KeyLength長度過大，而影響可以基於內存的索引記錄數量，進而影響基於內存的索引命中率，而基於硬盤進行索引查詢性能不好。嚴重影響數據庫服務器總體的性能表現。

自定義序列表

所謂自定義序列表，就是在庫中建一張用於生成序列的表來存儲序列信息，序列生成的策略經過程序層面來實現。以下所示，構建一張序列表：

CREATE TABLE `sequence` (
    `name` varchar(50) NOT NULL,
    `id` bigint(20) unsigned NOT NULL DEFAULT '0',
    PRIMARY KEY (`name`)
) ENGINE=InnoDB;

注意區別，id字段不是自增的，也不是主鍵。在使用前，咱們須要先插入一些初始化數據：

INSERT INTO `sequence` (`name`) VALUES 
('users'), ('photos'), ('albums'), ('comments');

接下來，咱們能夠經過執行下面的SQL語句來得到新的照片ID：

UPDATE `sequence` SET `id` = LAST_INSERT_ID(`id` + 1) WHERE `name` = 'photos';
SELECT LAST_INSERT_ID();

咱們執行了一個更新操做，將id字段增長1，並將增長後的值傳遞到LAST_INSERT_ID函數， 從而指定了LAST_INSERT_ID的返回值。

實際上，咱們不必定須要預先指定序列的名字。若是咱們如今須要一種新的序列，咱們能夠直接執行下面的SQL語句：

INSERT INTO `sequence` (`name`) VALUES('new_business') ON DUPLICATE KEY UPDATE `id` = LAST_INSERT_ID(`id` + 1);
SELECT LAST_INSERT_ID();

這種方案的問題在於序列生成的邏輯脫離了數據庫層，由應用層負責，增長了開發複雜度。固然，其實能夠用spring來解決這一問題，由於在spring JDBC中已經對這種序列生成邏輯進行了簡單的封裝。
咱們能夠看一下spring的相關源代碼：MySQLMaxValueIncrementer.

@Override
    protected synchronized long getNextKey() throws DataAccessException {
        if (this.maxId == this.nextId) {
            /*
            * Need to use straight JDBC code because we need to make sure that the insert and select
            * are performed on the same connection (otherwise we can't be sure that last_insert_id()
            * returned the correct value)
            */
            Connection con = DataSourceUtils.getConnection(getDataSource());
            Statement stmt = null;
            try {
                stmt = con.createStatement();
                DataSourceUtils.applyTransactionTimeout(stmt, getDataSource());
                // Increment the sequence column...
                String columnName = getColumnName();
                stmt.executeUpdate("update "+ getIncrementerName() + " set " + columnName +
                        " = last_insert_id(" + columnName + " + " + getCacheSize() + ")");
                // Retrieve the new max of the sequence column...
                ResultSet rs = stmt.executeQuery(VALUE_SQL);
                try {
                    if (!rs.next()) {
                        throw new DataAccessResourceFailureException("last_insert_id() failed after executing an update");
                    }
                    this.maxId = rs.getLong(1);
                }
                finally {
                    JdbcUtils.closeResultSet(rs);
                }
                this.nextId = this.maxId - getCacheSize() + 1;
            }
            catch (SQLException ex) {
                throw new DataAccessResourceFailureException("Could not obtain last_insert_id()", ex);
            }
            finally {
                JdbcUtils.closeStatement(stmt);
                DataSourceUtils.releaseConnection(con, getDataSource());
            }
        }
        else {
            this.nextId++;
        }
        return this.nextId;
    }

spring的實現也就是經過update語句對incrementerName表裏的columnName 列進行遞增，並經過mysql的last_insert_id()返回最近生成的值。並保證了事務性及方法的併發支持。只是這個實現有些過於簡單，好比：一個表對應一個序列的作法在實際應用開發中顯得過於零碎，因此在實際應用中須要對其實現進行修改，實現一條記錄對應一個序列的策略。另外對水平分片的支持並不在這一實現考慮範圍內。同時，這種作法依然沒法迴避表鎖的機制，因此這裏經過CacheSize()的作法，實現了一次申請並緩存在內存中，以減小表鎖的發生頻率。

如何解決水平分片的需求

UUID

因爲UUID出現重複的機率基本能夠忽略，因此對分片是天生支持的。

獨立的序列庫

單獨創建一個庫用來生成ID，在Shard中的每張表在這個ID庫中都有一個對應的表，而這個對應的表只有一個字段， 這個字段是自增的。當咱們須要插入新的數據，咱們首先在ID庫中的相應表中插入一條記錄，以此獲得一個新的ID， 而後將這個ID做爲插入到Shard中的數據的主鍵。這個方法的缺點就是須要額外的插入操做，若是ID庫變的很大， 性能也會隨之下降。因此必定要保證ID庫的數據集不要太大，一個辦法是按期清理前面的記錄

複合標識符

這種作法是經過聯合主鍵的策略，即經過兩個字段來生成一個惟一標識，前半部分是分片標識符，後半部分是本地生成的標識符（好比使用AUTO_INCREMENT生成）

帶分庫策略的自定義序列表

這種作法能夠基於上面提到的自定義序列表的方法的基礎上，作一些技巧性的調整。即以下：

UPDATE `sequence` SET `id` = LAST_INSERT_ID(`id` + 1) WHERE `name` = 'photos';
SELECT LAST_INSERT_ID();

這裏的id初始值設定上要求不一樣的分片取不一樣的值，且必須連續。同時將每次遞增的步長設定爲服務器數目。
好比有3臺機器，那麼咱們只要將初始值分別設置爲1，2，3. 而後執行下面的語句便可：

UPDATE `sequence` SET `id` = LAST_INSERT_ID(`id` + 3) WHERE `name` = 'photos';
SELECT LAST_INSERT_ID();

這就能夠解決主鍵生成衝突的問題。可是若是在運行一段時間後要進行動態擴充分片數的時候，須要對序列初始值作一次調整，以確保其連續性，不然依然可能存在衝突的可能。固然這些邏輯能夠封裝在數據訪問層的代碼中。

主鍵的必要性

表中每一行都應該有能夠惟一標識本身的一列（或一組列）。雖然並不老是都須要主鍵，但大多數數據庫設計人員都應保證他們建立的每一個表有一個主鍵，以便於之後數據操縱和管理。其實即便你不建主鍵，MySQL（InnoDB引擎）也會本身創建一個隱藏6字節的ROWID做爲主鍵列，詳細能夠參見[這裏]

由於，InnoDB引擎使用匯集索引，數據記錄自己被存於主索引（一顆B+Tree）的葉子節點上。這就要求同一個葉子節點內（大小爲一個內存頁或磁盤頁）的各條數據記錄按主鍵順序存放，所以每當有一條新的記錄插入時，MySQL 會根據其主鍵將其插入適當的節點和位置，若是頁面達到裝載因子（InnoDB默認爲15/16），則開闢一個新的頁（節點）

因此在使用innoDB表時要避免隨機的（不連續且值的分佈範圍很是大）聚簇索引，特別是針對I/O密集型的應用。例如：從性能角度考慮，使用UUID的方案就會致使聚簇索引的插入變得徹底隨機。

主鍵的數據類型選擇

關於主鍵的類型選擇上最多見的爭論是用整型仍是字符型的問題，關於這個問題《高性能MySQL》一書中有明確論斷：
整數一般是標識列的最好選擇，由於它很快且可使用AUTO_INCREAMENT,若是可能，應該避免使用字符串類型做爲標識列，由於很消耗空間，且一般比數字類型慢。

若是是使用MyISAM，則就更不能用字符型，由於MyISAM默認會對字符型採用壓縮引擎，從而致使查詢變得很是慢。 參考： 一、http://www.cnblogs.com/lsx1993/p/4663147.html 二、http://www.cnblogs.com/zhoujinyi/p/3433823.html 三、http://www.zolazhou.com/posts/primary-key-selection-in-database-partition-design/ 四、《高性能MySQL》 五、《高可用MySQL》

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程