欧美成人精品手机在线观看_69视频国产_动漫精品第一页_日韩中文字幕网 - 日本欧美一区二区

整數類型的 UNSIGNED 屬性有什么用？

MySQL 中的整數類型可以使用可選的 UNSIGNED 屬性來表示不允許負值的無符號整數。使用 UNSIGNED 屬性可以將正整數的上限提高一倍，因為它不需要存儲負數值。

例如， TINYINT UNSIGNED 類型的取值范圍是 0 ~ 255，而普通的 TINYINT 類型的值范圍是 -128 ~ 127。INT UNSIGNED 類型的取值范圍是 0 ~ 4,294,967,295，而普通的 INT 類型的值范圍是 -2,147,483,648 ~ 2,147,483,647。

對于從 0 開始遞增的 ID 列，使用 UNSIGNED 屬性可以非常適合，因為不允許負值并且可以擁有更大的上限范圍，提供了更多的 ID 值可用。

char和varchar的區別

CHAR

• CHAR類型用于存儲固定長度字符串：MySQL總是根據定義的字符串長度分配足夠的空間。當存儲CHAR值時，MySQL會刪除字符串中的末尾空格同時，CHAR值會根據需要采用空格進行剩余空間填充，以方便比較和檢索。但正因為其長度固定，所以會占據多余的空間，也是一種空間換時間的策略；

• CHAR適合存儲很短或長度近似的字符串。例如，CHAR非常適合存儲密碼的MD5值、定長的身份證等，因為這些是定長的值。

• 對于經常變更的數據，CHAR也比VARCHAR更好，因為定長的CHAR類型占用磁盤的存儲空間是連續分配的，不容易產生碎片。

• 對于非常短的列，CHAR比VARCHAR在存儲空間上也更有效率。例如用CHAR(1)來存儲只有Y和N的值，如果采用單字節字符集只需要一個字節，但是VARCHAR(1)卻需要兩個字節，因為還有一個記錄長度的額外字節。

VARCHAR：

• VARCHAR類型用于存儲可變長度字符串，是最常見的字符串數據類型。它比固定長度類型更節省空間，因為它僅使用必要的空間(根據實際字符串的長度改變存儲空間)。

• VARCHAR需要使用1或2個額外字節記錄字符串的長度：如果列的最大長度小于或等于255字節，則只使用1個字節表示，否則使用2個字節。假設采用latinl字符集，一個VARCHAR(10)的列需要11個字節的存儲空間。VARCHAR(1000)的列則需要1002 個字節，因為需要2個字節存儲長度信息。

• VARCHAR節省了存儲空間，所以對性能也有幫助。但是，由于行是變長的，在UPDATE時可能使行變得比原來更長，這就導致需要做額外的工作。如果一個行占用的空間增長，并且在頁內沒有更多的空間可以存儲，在這種情況下，不同的存儲引擎的處理方式是不一樣的。例如，MylSAM會將行拆成不同的片段存儲，InnoDB則需要分裂頁來使行可以放進頁內。

• 操作內存的方式：對于varchar數據類型來說，硬盤上的存儲空間雖然都是根據字符串的實際長度來存儲空間的，但在內存中是根據varchar類型定義的長度來分配占用的內存空間的，而不是根據字符串的實際長度來分配的。顯然，這對于排序和臨時表會較大的性能影響。

VARCHAR(100)和 VARCHAR(10)的區別是什么？

VARCHAR(100)和 VARCHAR(10)都是變長類型，表示能存儲最多 100 個字符和 10 個字符。因此，VARCHAR (100) 可以滿足更大范圍的字符存儲需求，有更好的業務拓展性。而 VARCHAR(10)存儲超過 10 個字符時，就需要修改表結構才可以。

雖說 VARCHAR(100)和 VARCHAR(10)能存儲的字符范圍不同，但二者存儲相同的字符串，所占用磁盤的存儲空間其實是一樣的，這也是很多人容易誤解的一點。

不過，VARCHAR(100) 會消耗更多的內存。這是因為 VARCHAR 類型在內存中操作時，通常會分配固定大小的內存塊來保存值，即使用字符類型中定義的長度。例如在進行排序的時候，VARCHAR(100)是按照 100 這個長度來進行的，也就會消耗更多內存。

DECIMAL 和 FLOAT/DOUBLE 的區別是什么？

DECIMAL 和 FLOAT 的區別是：DECIMAL 是定點數，FLOAT/DOUBLE 是浮點數。DECIMAL 可以存儲精確的小數值，FLOAT/DOUBLE 只能存儲近似的小數值。

DECIMAL 用于存儲具有精度要求的小數，例如與貨幣相關的數據，可以避免浮點數帶來的精度損失。

在 Java 中，MySQL 的 DECIMAL 類型對應的是 Java 類 java.math.BigDecimal。

int(10)和char(10)的區別？

int(10)中的10表示的是顯示數據的長度，而char(10)表示的是存儲數據的長度。

為什么不推薦使用 TEXT 和 BLOB？

數據庫規范通常不推薦使用 BLOB 和 TEXT 類型，這兩種類型具有一些缺點和限制，例如：

• 不能有默認值。

• 在使用臨時表時無法使用內存臨時表，只能在磁盤上創建臨時表（《高性能 MySQL》書中有提到）。

• 檢索效率較低。

• 不能直接創建索引，需要指定前綴長度。

• 可能會消耗大量的網絡和 IO 帶寬。

• 可能導致表上的 DML 操作變慢。

• ……

DATETIME 和 TIMESTAMP 的區別是什么？

DATETIME 類型沒有時區信息，TIMESTAMP 和時區有關。

TIMESTAMP 只需要使用 4 個字節的存儲空間，但是 DATETIME 需要耗費 8 個字節的存儲空間。但是，這樣同樣造成了一個問題，Timestamp 表示的時間范圍更小。

• DATETIME：1000-01-01 00:00:00 ~ 9999-12-31 23:59:59

• Timestamp：1970-01-01 00:00:01 ~ 2037-12-31 23:59:59

Boolean 類型如何表示？

MySQL 中沒有專門的布爾類型，而是用 TINYINT(1) 類型來表示布爾值。TINYINT(1) 類型可以存儲 0 或 1，分別對應 false 或 true。

為什么不建議使用null作為默認值

Mysql不建議用Null作為列默認值不是因為不能使用索引，而是因為：

• 索引列存在 NULL 就會導致優化器在做索引選擇的時候更加復雜，更加難以優化。比如進行索引統計時，count(1),max(),min() 會省略值為NULL 的行。

• NULL 值是一個沒意義的值，但是它會占用物理空間，所以會帶來的存儲空間的問題，因為 InnoDB 存儲記錄的時候，如果表中存在允許為 NULL 的字段，那么行格式 (opens new window)中至少會用 1 字節空間存儲 NULL 值列表。建議用""或默認值0來代替NULL

不建議使用null作為默認值，并且建議必須設置默認值，原因如下：

• 既然都不可為空了，那就必須要有默認值，否則不插入這列的話，就會報錯；

• 數據庫不應該是用來查問題的，不能靠mysql報錯來告知業務有問題，該不該插入應該由業務說了算；

• 對于DBA來說，允許使用null是沒有規范的，因為不同的人不同的用法。

但像合同生效時間、獲獎時間 等這種不可控字段，是可以不設置默認值的，但同樣需要not null

為什么禁止使用外鍵

• 外鍵會降低數據庫的性能。在MySQL中，外鍵會自動加上索引，這會使得對該表的查詢等操作變得緩慢，尤其是在大型數據表中。

• 外鍵也會限制了表結構的調整和更改。在實際應用中，表結構經常需要進行更改，而如果表之間使用了外鍵約束，這些更改可能會非常難以實現。因為更改一個表的結構，需要涉及到所有以其為父表的子表，這會導致長時間鎖定整個數據庫表，甚至可能會導致數據丟失。

• 在MySQL中，外鍵約束可能還會引發死鎖問題。當想要對多個表中的數據進行插入、更新、刪除操作時，由于外鍵約束的存在，可能會導致死鎖，需要等待其他事務釋放鎖。

• MySQL中使用外鍵還會增加開發難度。開發人員需要處理數據在表之間的關系，而這樣的處理需要花費更多的時間和精力，以及對數據庫的深入理解。同時，外鍵也會增加代碼的復雜度，使得SQL語句變得難以理解和調試。

在阿里巴巴開發手冊中也有提到，傳送門

使用自增主鍵有什么好處？

自增主鍵可以讓主鍵索引盡量地保持遞增順序插入，避免了頁分裂，因此索引更緊湊，在查詢的時候，效率也就更高。

自增主鍵保存在什么地方？

不同的引擎對于自增值的保存策略不同：

• MyISAM引擎的自增值保存在數據文件中。

• 在MySQL8.0以前，InnoDB引擎的自增值是存在內存中。MySQL重啟之后內存中的這個值就丟失了，每次重啟后第一次打開表的時候，會找自增值的最大值max(id)，然后將最大值加1作為這個表的自增值；MySQL8.0版本會將自增值的變更記錄在redo log中，重啟時依靠redo log恢復。

自增主鍵一定是連續的嗎？

不一定，有幾種情況會導致自增主鍵不連續。

1、唯一鍵沖突導致自增主鍵不連續。當我們向一個自增主鍵的InnoDB表中插入數據的時候，如果違反表中定義的唯一索引的唯一約束，會導致插入數據失敗。此時表的自增主鍵的鍵值是會向后加1滾動的。下次再次插入數據的時候，就不能再使用上次因插入數據失敗而滾動生成的鍵值了，必須使用新滾動生成的鍵值。

2、事務回滾導致自增主鍵不連續。當我們向一個自增主鍵的InnoDB表中插入數據的時候，如果顯式開啟了事務，然后因為某種原因最后回滾了事務，此時表的自增值也會發生滾動，而接下里新插入的數據，也將不能使用滾動過的自增值，而是需要重新申請一個新的自增值。

3、批量插入導致自增值不連續。MySQL有一個批量申請自增id的策略：

• 語句執行過程中，第一次申請自增id，分配1個自增id

• 1個用完以后，第二次申請，會分配2個自增id

• 2個用完以后，第三次申請，會分配4個自增id

• 依次類推，每次申請都是上一次的兩倍（最后一次申請不一定全部使用）

如果下一個事務再次插入數據的時候，則會基于上一個事務申請后的自增值基礎上再申請。此時就出現自增值不連續的情況出現。

4、自增步長不是1，也會導致自增主鍵不連續。

InnoDB的自增值為什么不能回收利用？

主要為了提升插入數據的效率和并行度。

假設有兩個并行執行的事務，在申請自增值的時候，為了避免兩個事務申請到相同的自增 id，肯定要加鎖，然后順序申請。

假設事務 A 申請到了 id=2， 事務 B 申請到 id=3，那么這時候表 t 的自增值是 4，之后繼續執行。

事務 B 正確提交了，但事務 A 出現了唯一鍵沖突。

如果允許事務 A 把自增 id 回退，也就是把表 t 的當前自增值改回 2，那么就會出現這樣的情況：表里面已經有 id=3 的行，而當前的自增 id 值是 2。

接下來，繼續執行的其他事務就會申請到 id=2，然后再申請到 id=3。這時，就會出現插入語句報錯“主鍵沖突”。

而為了解決這個主鍵沖突，有兩種方法：

• 每次申請 id 之前，先判斷表里面是否已經存在這個 id。如果存在，就跳過這個 id。但是，這個方法的成本很高。因為，本來申請 id 是一個很快的操作，現在還要再去主鍵索引樹上判斷 id 是否存在。

• 把自增 id 的鎖范圍擴大，必須等到一個事務執行完成并提交，下一個事務才能再申請自增 id。這個方法的問題，就是鎖的粒度太大，系統并發能力大大下降。

可見，這兩個方法都會導致性能問題。

因此，InnoDB 放棄了“允許自增 id 回退”這個設計，語句執行失敗也不回退自增 id。

utf8 、utf8mb3和 utf8mb4的區別

utf8mb3：只支持最長三個字節的BMP（Basic Multilingual Plane，基本多文種平面）字符（不支持補充字符）。

utf8mb4：mb4即 most bytes 4，即最多使用4個字節來表示完整的UTF-8，具有以下特征：

• 支持BMP和補充字符。

• 每個多字節字符最多需要四個字節。

utf8mb4是utf8的超集并完全兼容它，是MySQL 在 5.5.3 版本之后增加的一個新的字符集，能夠用四個字節存儲更多的字符，幾乎包含了世界上所有能看到見的語言字符。

• 差異比較

如何選擇？一句話就是，根據具體的業務需求和實際情況，選擇最合適的字符集。

轉自https://www.cnblogs.com/seven97-top/p/18537862