MySQL的這6大雷區(qū)，大部分人都會(huì)踩中！
前言
有些小伙伴在工作中，可能經(jīng)常遇到這樣的場(chǎng)景：系統(tǒng)上線(xiàn)初期運(yùn)行良好，隨著數(shù)據(jù)量增長(zhǎng)，突然某天接口超時(shí)、CPU飆升、甚至整個(gè)系統(tǒng)癱瘓。
排查半天，發(fā)現(xiàn)是某個(gè)SQL語(yǔ)句寫(xiě)的有問(wèn)題，或者是數(shù)據(jù)庫(kù)配置不當(dāng)導(dǎo)致的。
今天這篇文章我就從淺入深，帶你徹底避開(kāi)MySQL的6大常見(jiàn)雷區(qū)，希望的對(duì)你會(huì)有所幫助。
為什么MySQL雷區(qū)如此之多？
在深入具體雷區(qū)之前，我們先聊聊為什么MySQL這么容易踩坑。
這背后有幾個(gè)深層次原因：
- 看似簡(jiǎn)單：MySQL語(yǔ)法簡(jiǎn)單，入門(mén)容易，讓很多人低估了它的復(fù)雜性
- 默認(rèn)配置坑多：MySQL的默認(rèn)配置往往不是最優(yōu)的，需要根據(jù)業(yè)務(wù)場(chǎng)景調(diào)整
- 漸進(jìn)式問(wèn)題：很多問(wèn)題在數(shù)據(jù)量小的時(shí)候不會(huì)暴露，等到暴露時(shí)已經(jīng)為時(shí)已晚
- 知識(shí)更新快：從5.6到5.7再到8.0，每個(gè)版本都有重要變化，需要持續(xù)學(xué)習(xí)
有些小伙伴在工作中，可能直接用默認(rèn)配置部署MySQL，或者在寫(xiě)SQL時(shí)只關(guān)注功能實(shí)現(xiàn)，忽略了性能問(wèn)題。
這就是為什么我們需要系統(tǒng)性地了解這些雷區(qū)。
好了，讓我們開(kāi)始今天的主菜。我將從最常見(jiàn)的索引失效，逐步深入到復(fù)雜的死鎖問(wèn)題，確保每個(gè)雷區(qū)都講透、講懂。
雷區(qū)一：索引失效的常見(jiàn)場(chǎng)景
索引是MySQL性能的基石，但錯(cuò)誤的使用方式會(huì)讓索引失效，導(dǎo)致全表掃描。
這是最常見(jiàn)的性能雷區(qū)。
為什么索引會(huì)失效？
索引失效的本質(zhì)是MySQL優(yōu)化器認(rèn)為使用索引的成本高于全表掃描。
了解這些場(chǎng)景，可以幫助我們寫(xiě)出更高效的SQL。
示例場(chǎng)景
-- 創(chuàng)建測(cè)試表
CREATE TABLE user (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(50),
age INT,
email VARCHAR(100),
created_time DATETIME,
INDEX idx_name (name),
INDEX idx_age (age),
INDEX idx_created_time (created_time)
);
-- 雷區(qū)1.1：對(duì)索引列進(jìn)行函數(shù)操作
-- 錯(cuò)誤寫(xiě)法：索引失效
EXPLAIN SELECT * FROM user WHERE DATE(created_time) = '2023-01-01';
-- 正確寫(xiě)法：使用范圍查詢(xún)
EXPLAIN SELECT * FROM user
WHERE created_time >= '2023-01-01 00:00:00'
AND created_time < '2023-01-02 00:00:00';
-- 雷區(qū)1.2：隱式類(lèi)型轉(zhuǎn)換
-- 錯(cuò)誤寫(xiě)法：name是字符串，但用了數(shù)字，導(dǎo)致索引失效
EXPLAIN SELECT * FROM user WHERE name = 123;
-- 正確寫(xiě)法：類(lèi)型匹配
EXPLAIN SELECT * FROM user WHERE name = '123';
-- 雷區(qū)1.3：前導(dǎo)模糊查詢(xún)
-- 錯(cuò)誤寫(xiě)法：LIKE以%開(kāi)頭，索引失效
EXPLAIN SELECT * FROM user WHERE name LIKE '%三%';
-- 正確寫(xiě)法：非前導(dǎo)模糊查詢(xún)，可以使用索引
EXPLAIN SELECT * FROM user WHERE name LIKE '蘇%';
-- 雷區(qū)1.4：OR條件使用不當(dāng)
-- 錯(cuò)誤寫(xiě)法：age有索引，email無(wú)索引，導(dǎo)致整個(gè)查詢(xún)無(wú)法使用索引
EXPLAIN SELECT * FROM user WHERE age = 25 OR email = 'test@example.com';
-- 正確寫(xiě)法：使用UNION優(yōu)化OR查詢(xún)
EXPLAIN
SELECT * FROM user WHERE age = 25
UNION
SELECT * FROM user WHERE email = 'test@example.com';
深度剖析
有些小伙伴在工作中可能會(huì)疑惑：為什么這些寫(xiě)法會(huì)導(dǎo)致索引失效？
-
函數(shù)操作破壞索引有序性
- 索引是按照列值的原始順序存儲(chǔ)的
- 對(duì)列使用函數(shù)后，MySQL無(wú)法利用索引的有序性
- 必須掃描所有索引項(xiàng)，計(jì)算函數(shù)值后再比較
-
隱式類(lèi)型轉(zhuǎn)換的本質(zhì)
- 當(dāng)類(lèi)型不匹配時(shí)，MySQL會(huì)進(jìn)行隱式轉(zhuǎn)換
- 實(shí)際上相當(dāng)于：
CAST(name AS SIGNED) = 123 - 對(duì)索引列進(jìn)行了函數(shù)操作，導(dǎo)致失效
-
前導(dǎo)模糊查詢(xún)的B+樹(shù)遍歷
- B+樹(shù)索引按照前綴排序
LIKE '蘇%'可以利用前綴匹配LIKE '%三'無(wú)法確定前綴，必須全表掃描
避坑指南
- 避免對(duì)索引列進(jìn)行函數(shù)操作
- 確保查詢(xún)條件與索引列類(lèi)型匹配
- 謹(jǐn)慎使用前導(dǎo)模糊查詢(xún)
- 使用UNION優(yōu)化復(fù)雜的OR查詢(xún)
雷區(qū)二：事務(wù)隔離級(jí)別與幻讀
事務(wù)隔離級(jí)別是MySQL中比較復(fù)雜的概念，理解不當(dāng)會(huì)導(dǎo)致數(shù)據(jù)不一致和性能問(wèn)題。
為什么事務(wù)隔離級(jí)別重要？
不同的隔離級(jí)別在數(shù)據(jù)一致性、性能、并發(fā)性之間做出不同權(quán)衡。
選擇不當(dāng)會(huì)出現(xiàn)臟讀、不可重復(fù)讀、幻讀等問(wèn)題。
示例場(chǎng)景
-- 查看當(dāng)前事務(wù)隔離級(jí)別
SELECT @@transaction_isolation;
-- 設(shè)置隔離級(jí)別為REPEATABLE-READ（默認(rèn)）
SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ;
-- 場(chǎng)景：轉(zhuǎn)賬業(yè)務(wù)中的幻讀問(wèn)題
-- 會(huì)話(huà)1：事務(wù)A
START TRANSACTION;
SELECT COUNT(*) FROM account WHERE user_id = 1001; -- 返回2
-- 會(huì)話(huà)2：事務(wù)B
START TRANSACTION;
INSERT INTO account (user_id, balance) VALUES (1001, 500);
COMMIT;
-- 會(huì)話(huà)1：事務(wù)A繼續(xù)
SELECT COUNT(*) FROM account WHERE user_id = 1001; -- 仍然返回2（可重復(fù)讀）
UPDATE account SET balance = balance + 100 WHERE user_id = 1001; -- 影響3行！
SELECT COUNT(*) FROM account WHERE user_id = 1001; -- 返回3，出現(xiàn)幻讀！
COMMIT;
深度剖析
有些小伙伴在工作中可能遇到過(guò)：明明查詢(xún)時(shí)不存在的數(shù)據(jù)，更新時(shí)卻影響到了。這就是典型的幻讀問(wèn)題。
幻讀的本質(zhì)：
- 在可重復(fù)讀隔離級(jí)別下，普通SELECT看不到其他事務(wù)的插入
- 但UPDATE/DELETE會(huì)看到所有已提交的數(shù)據(jù)
- 這導(dǎo)致同一個(gè)事務(wù)內(nèi)，查詢(xún)和更新看到的數(shù)據(jù)不一致
MySQL的解決方案：
- Next-Key Lock：MySQL通過(guò)間隙鎖防止幻讀
- 在REPEATABLE-READ級(jí)別，MySQL不僅鎖住記錄，還鎖住記錄之間的間隙
為了理解間隙鎖的工作原理，我畫(huà)了一個(gè)鎖范圍示意圖：
這個(gè)圖展示了當(dāng)查詢(xún)id > 8時(shí)，MySQL會(huì)鎖定[5,10]的間隙、ID=10的記錄，以及[10,∞]的間隙，防止其他事務(wù)插入ID>8的數(shù)據(jù)。
避坑指南
- 理解不同隔離級(jí)別的特性
- 在REPEATABLE-READ下，注意UPDATE可能產(chǎn)生幻讀
- 對(duì)于需要絕對(duì)一致性的場(chǎng)景，使用SERIALIZABLE隔離級(jí)別
- 合理設(shè)計(jì)事務(wù)邊界，避免長(zhǎng)事務(wù)
雷區(qū)三：大數(shù)據(jù)量下的分頁(yè)優(yōu)化
分頁(yè)查詢(xún)是Web應(yīng)用中最常見(jiàn)的操作，但在大數(shù)據(jù)量下性能急劇下降。
為什么分頁(yè)會(huì)變慢？
LIMIT offset, size在offset很大時(shí)，需要掃描并跳過(guò)大量記錄，造成性能瓶頸。
示例場(chǎng)景
-- 創(chuàng)建測(cè)試表，假設(shè)有1000萬(wàn)數(shù)據(jù)
CREATE TABLE order (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
user_id INT,
amount DECIMAL(10,2),
status TINYINT,
created_time DATETIME,
INDEX idx_created_time (created_time)
);
-- 雷區(qū)：傳統(tǒng)的分頁(yè)寫(xiě)法
-- 當(dāng)offset達(dá)到500萬(wàn)時(shí)，性能急劇下降
EXPLAIN SELECT * FROM order
ORDER BY created_time DESC
LIMIT 5000000, 20;
-- 優(yōu)化方案1：游標(biāo)分頁(yè)（推薦）
-- 第一頁(yè)
SELECT * FROM order
ORDER BY created_time DESC, id DESC
LIMIT 20;
-- 第二頁(yè)：記住上一頁(yè)最后一條記錄的created_time和id
SELECT * FROM order
WHERE created_time < '2023-06-01 10:00:00'
OR (created_time = '2023-06-01 10:00:00' AND id < 1000000)
ORDER BY created_time DESC, id DESC
LIMIT 20;
-- 優(yōu)化方案2：子查詢(xún)優(yōu)化（適用于非游標(biāo)場(chǎng)景）
SELECT * FROM order
WHERE id >= (
SELECT id FROM order
ORDER BY created_time DESC
LIMIT 5000000, 1
)
ORDER BY created_time DESC
LIMIT 20;
深度剖析
有些小伙伴在工作中可能發(fā)現(xiàn)，為什么offset越大查詢(xún)?cè)铰?/p>
傳統(tǒng)分頁(yè)的性能瓶頸：
- 大量無(wú)效IO：需要讀取并跳過(guò)offset條記錄
- 回表成本：對(duì)于非覆蓋索引，需要回表查詢(xún)完整數(shù)據(jù)
- 排序開(kāi)銷(xiāo)：大數(shù)據(jù)量的排序可能在磁盤(pán)進(jìn)行
游標(biāo)分頁(yè)的優(yōu)勢(shì)：
- 直接定位到起始位置，無(wú)需跳過(guò)大量記錄
- 利用索引的有序性，避免排序操作
- 性能穩(wěn)定，不隨數(shù)據(jù)量增長(zhǎng)而下降
為了理解傳統(tǒng)分頁(yè)與游標(biāo)分頁(yè)的區(qū)別，我畫(huà)了一個(gè)對(duì)比圖：
避坑指南
- 優(yōu)先使用游標(biāo)分頁(yè)（基于游標(biāo)或時(shí)間戳）
- 如果必須使用傳統(tǒng)分頁(yè)，使用子查詢(xún)優(yōu)化
- 確保排序字段有索引
- 前端配合使用無(wú)限滾動(dòng)或游標(biāo)分頁(yè)UI
雷區(qū)四：字符集與排序規(guī)則陷阱
字符集問(wèn)題經(jīng)常在系統(tǒng)國(guó)際化或多語(yǔ)言支持時(shí)暴露，處理不當(dāng)會(huì)導(dǎo)致亂碼、排序錯(cuò)誤、索引失效。
為什么字符集如此重要？
不同的字符集支持不同的字符范圍，排序規(guī)則影響字符串比較和排序結(jié)果。
示例場(chǎng)景
-- 查看字符集配置
SHOW VARIABLES LIKE 'character_set%';
SHOW VARIABLES LIKE 'collation%';
-- 雷區(qū)：UTF8不是真正的UTF-8
-- MySQL的utf8最多支持3字節(jié)，無(wú)法存儲(chǔ)emoji等4字節(jié)字符
CREATE TABLE user_utf8 (
id INT PRIMARY KEY,
name VARCHAR(50) CHARACTER SET utf8
);
-- 插入emoji表情失敗
INSERT INTO user_utf8 VALUES (1, '張三??'); -- 錯(cuò)誤！
-- 正確：使用utf8mb4
CREATE TABLE user_utf8mb4 (
id INT PRIMARY KEY,
name VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
);
-- 插入emoji成功
INSERT INTO user_utf8mb4 VALUES (1, '張三??'); -- 成功！
-- 雷區(qū)：排序規(guī)則影響查詢(xún)結(jié)果
CREATE TABLE product (
id INT PRIMARY KEY,
name VARCHAR(100)
) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
-- 大小寫(xiě)不敏感查詢(xún)
SELECT * FROM product WHERE name = 'apple'; -- 會(huì)匹配'Apple', 'APPLE'
-- 如果需要大小寫(xiě)敏感，使用binary或特定collation
SELECT * FROM product WHERE name = BINARY 'apple'; -- 只匹配'apple'
深度剖析
有些小伙伴在工作中可能遇到過(guò)存儲(chǔ)emoji失敗，或者查詢(xún)時(shí)大小寫(xiě)匹配異常，這都是字符集配置不當(dāng)導(dǎo)致的。
UTF8 vs UTF8MB4：
- utf8：MySQL歷史上的"假UTF-8"，最多3字節(jié)，不支持emoji、部分中文生僻字
- utf8mb4：真正的UTF-8實(shí)現(xiàn)，支持4字節(jié)，推薦使用
排序規(guī)則的影響：
_ci結(jié)尾：大小寫(xiě)不敏感（Case Insensitive）_cs結(jié)尾：大小寫(xiě)敏感（Case Sensitive）_bin結(jié)尾：二進(jìn)制比較，完全匹配
為了理解不同字符集的存儲(chǔ)范圍，我畫(huà)了一個(gè)對(duì)比圖：
避坑指南
- 新項(xiàng)目一律使用utf8mb4字符集
- 根據(jù)業(yè)務(wù)需求選擇合適的排序規(guī)則
- 數(shù)據(jù)庫(kù)、表、字段、連接字符集保持一致
- 遷移現(xiàn)有數(shù)據(jù)時(shí)注意字符集轉(zhuǎn)換
雷區(qū)五：外鍵與級(jí)聯(lián)操作的隱患
外鍵約束可以保證數(shù)據(jù)完整性，但使用不當(dāng)會(huì)帶來(lái)性能問(wèn)題和復(fù)雜的維護(hù)成本。
為什么外鍵是雙刃劍？
外鍵在保證數(shù)據(jù)一致性的同時(shí)，會(huì)帶來(lái)鎖競(jìng)爭(zhēng)、維護(hù)復(fù)雜、遷移困難等問(wèn)題。
示例場(chǎng)景
-- 創(chuàng)建帶外鍵的表結(jié)構(gòu)
CREATE TABLE department (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(50) NOT NULL
);
CREATE TABLE employee (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(50) NOT NULL,
department_id INT,
FOREIGN KEY (department_id)
REFERENCES department(id)
ON DELETE CASCADE
ON UPDATE CASCADE
);
-- 雷區(qū)1：級(jí)聯(lián)刪除導(dǎo)致意外數(shù)據(jù)丟失
-- 刪除部門(mén)時(shí)，所有相關(guān)員工也被刪除，可能不是期望的行為
DELETE FROM department WHERE id = 1; -- 部門(mén)1的所有員工都被刪除！
-- 雷區(qū)2：外鍵鎖競(jìng)爭(zhēng)
-- 會(huì)話(huà)1：刪除部門(mén)
START TRANSACTION;
DELETE FROM department WHERE id = 1; -- 持有部門(mén)1的鎖
-- 會(huì)話(huà)2：在同一個(gè)部門(mén)插入員工（被阻塞）
START TRANSACTION;
INSERT INTO employee (name, department_id) VALUES ('新員工', 1); -- 等待鎖
-- 雷區(qū)3：數(shù)據(jù)遷移困難
-- 導(dǎo)入數(shù)據(jù)時(shí)必須按正確順序，否則外鍵約束失敗
深度剖析
有些小伙伴在工作中可能發(fā)現(xiàn)，系統(tǒng)并發(fā)量上來(lái)后，經(jīng)常出現(xiàn)鎖等待超時(shí)，外鍵約束是常見(jiàn)原因之一。
外鍵的性能影響：
- 鎖范圍擴(kuò)大：操作父表時(shí)需要檢查子表，可能鎖定更多數(shù)據(jù)
- 死鎖風(fēng)險(xiǎn)：多表之間的外鍵關(guān)系容易形成死鎖環(huán)路
- 并發(fā)下降：外鍵檢查需要額外加鎖，降低系統(tǒng)并發(fā)能力
級(jí)聯(lián)操作的風(fēng)險(xiǎn)：
ON DELETE CASCADE：誤刪父表記錄會(huì)導(dǎo)致大量子表數(shù)據(jù)丟失ON UPDATE CASCADE：更新主鍵時(shí)傳播到所有子表，性能影響大
為了理解外鍵鎖的競(jìng)爭(zhēng)關(guān)系，我畫(huà)了一個(gè)鎖等待示意圖：
避坑指南
- 高并發(fā)場(chǎng)景慎用外鍵，可在應(yīng)用層保證數(shù)據(jù)一致性
- 如果使用外鍵，避免ON DELETE/UPDATE CASCADE
- 使用軟刪除替代物理刪除
- 批量操作時(shí)暫時(shí)禁用外鍵檢查
雷區(qū)六：連接池配置不當(dāng)
連接池配置看似簡(jiǎn)單，實(shí)則影響整個(gè)系統(tǒng)的穩(wěn)定性和性能。
配置不當(dāng)會(huì)導(dǎo)致連接泄露、池化失效等問(wèn)題。
為什么連接池如此關(guān)鍵？
數(shù)據(jù)庫(kù)連接是寶貴的資源，創(chuàng)建和銷(xiāo)毀成本很高。
連接池管理不當(dāng)會(huì)直接導(dǎo)致系統(tǒng)崩潰。
示例場(chǎng)景
// Spring Boot中的Druid連接池配置
@Configuration
public class DruidConfig {
@Bean
@ConfigurationProperties("spring.datasource.druid")
public DataSource dataSource() {
return DruidDataSourceBuilder.create().build();
}
}
// application.yml配置
spring:
datasource:
druid:
# 雷區(qū)1：初始連接數(shù)過(guò)大，浪費(fèi)資源
initial-size: 50
# 雷區(qū)2：最大連接數(shù)過(guò)小，并發(fā)時(shí)等待
max-active: 20
# 雷區(qū)3：最小空閑連接數(shù)不合理
min-idle: 5
# 雷區(qū)4：獲取連接超時(shí)時(shí)間過(guò)短
max-wait: 3000
# 雷區(qū)5：沒(méi)有配置連接有效性檢查
validation-query: SELECT 1
test-on-borrow: true
test-on-return: false
test-while-idle: true
time-between-eviction-runs-millis: 60000
min-evictable-idle-time-millis: 300000
深度剖析
有些小伙伴在工作中可能遇到過(guò)連接池耗盡、連接泄露等問(wèn)題，這都是配置不當(dāng)導(dǎo)致的。
連接池的核心參數(shù)：
- initial-size：初始連接數(shù)，不宜過(guò)大，避免啟動(dòng)時(shí)占用過(guò)多資源
- max-active：最大連接數(shù)，根據(jù)數(shù)據(jù)庫(kù)和服務(wù)器的處理能力設(shè)置
- min-idle：最小空閑連接，保持一定的預(yù)熱連接
- max-wait：獲取連接超時(shí)時(shí)間，避免線(xiàn)程長(zhǎng)時(shí)間阻塞
連接泄露的檢測(cè)與預(yù)防：
// 常見(jiàn)的連接泄露模式
public class UserService {
// 錯(cuò)誤寫(xiě)法：連接未關(guān)閉
public User getUser(int id) {
Connection conn = dataSource.getConnection();
// 執(zhí)行查詢(xún)...
// 忘記調(diào)用conn.close()
return user;
}
// 正確寫(xiě)法：使用try-with-resources
public User getUserCorrect(int id) {
try (Connection conn = dataSource.getConnection();
PreparedStatement stmt = conn.prepareStatement("SELECT * FROM user WHERE id = ?")) {
stmt.setInt(1, id);
ResultSet rs = stmt.executeQuery();
// 處理結(jié)果...
return user;
} catch (SQLException e) {
throw new RuntimeException(e);
}
}
}
為了理解連接池的工作機(jī)制，我畫(huà)了一個(gè)連接池狀態(tài)轉(zhuǎn)換圖：
避坑指南
- 根據(jù)業(yè)務(wù)壓力合理配置連接池參數(shù)
- 使用try-with-resources確保連接關(guān)閉
- 開(kāi)啟連接泄露檢測(cè)功能
- 監(jiān)控連接池狀態(tài)，設(shè)置合理的告警閾值
總結(jié)
經(jīng)過(guò)以上6大雷區(qū)的分析，相信你對(duì)MySQL的常見(jiàn)坑點(diǎn)有了更深入的理解。
雷區(qū)對(duì)比總結(jié)
| 雷區(qū) | 核心問(wèn)題 | 影響范圍 | 解決思路 |
|---|---|---|---|
| 索引失效 | 查詢(xún)寫(xiě)法不當(dāng) | 查詢(xún)性能 | 避免函數(shù)操作、類(lèi)型轉(zhuǎn)換 |
| 事務(wù)幻讀 | 隔離級(jí)別理解不足 | 數(shù)據(jù)一致性 | 合理選擇隔離級(jí)別、使用間隙鎖 |
| 分頁(yè)性能 | OFFSET過(guò)大 | 用戶(hù)體驗(yàn) | 使用游標(biāo)分頁(yè)、子查詢(xún)優(yōu)化 |
| 字符集問(wèn)題 | 配置不當(dāng) | 數(shù)據(jù)存儲(chǔ)、排序 | 統(tǒng)一使用utf8mb4、正確配置collation |
| 外鍵約束 | 級(jí)聯(lián)操作、鎖競(jìng)爭(zhēng) | 系統(tǒng)性能、數(shù)據(jù)安全 | 應(yīng)用層約束、慎用級(jí)聯(lián) |
| 連接池配置 | 參數(shù)不合理、連接泄露 | 系統(tǒng)穩(wěn)定性 | 合理配置、監(jiān)控告警 |
有些小伙伴在工作中，可能一開(kāi)始覺(jué)得這些問(wèn)題很復(fù)雜，但只要掌握了底層原理，就能在設(shè)計(jì)和開(kāi)發(fā)階段主動(dòng)避免。
記住，數(shù)據(jù)庫(kù)是系統(tǒng)的核心，它的穩(wěn)定性直接影響整個(gè)業(yè)務(wù)。
最后說(shuō)一句(求關(guān)注，別白嫖我)
如果這篇文章對(duì)您有所幫助，或者有所啟發(fā)的話(huà)，幫忙關(guān)注一下我的同名公眾號(hào)：蘇三說(shuō)技術(shù)，您的支持是我堅(jiān)持寫(xiě)作最大的動(dòng)力。
求一鍵三連：點(diǎn)贊、轉(zhuǎn)發(fā)、在看。
關(guān)注公眾號(hào)：【蘇三說(shuō)技術(shù)】，在公眾號(hào)中回復(fù)：進(jìn)大廠，可以免費(fèi)獲取我最近整理的10萬(wàn)字的面試寶典，好多小伙伴靠這個(gè)寶典拿到了多家大廠的offer。
更多經(jīng)常內(nèi)容在我的技術(shù)網(wǎng)站：http://www.susan.net.cn
浙公網(wǎng)安備 33010602011771號(hào)