最新国产好看的视频,伊人天堂AV在线,国产Aaaaaa视频,蜜臀视频在线观看一区,人妻av色图,密臀久久久精品影片,青青视频免费观看毛片,久草在线观看视,国产三级精品色情在线

MySql分庫(kù)分表深度指南之從策略到落地

 更新時(shí)間:2026年01月19日 16:31:58   作者:廋到被風(fēng)吹走  
文章介紹了MySQL分庫(kù)分表的策略及實(shí)施方法,包括分片鍵設(shè)計(jì)、中間件選型(如ShardingSphere、Mycat),以及如何處理跨分片查詢和數(shù)據(jù)遷移,通過(guò)案例和最佳實(shí)踐,文章展示了如何解決高并發(fā)、大數(shù)據(jù)量下的查詢和事務(wù)問(wèn)題,實(shí)現(xiàn)數(shù)據(jù)自治和高可用,感興趣的朋友跟隨小編一起看看吧

MySQL 分庫(kù)分表深度指南:從策略到落地

當(dāng)單表數(shù)據(jù)突破 5000萬(wàn)行 時(shí),B+樹索引深度達(dá)到5層,磁盤I/O暴增,簡(jiǎn)單查詢耗時(shí)超10秒。此時(shí)分庫(kù)分表成為必然選擇。本文將詳解 ShardingSphere/Mycat 中間件選型、分片鍵設(shè)計(jì)哲學(xué)及 Snowflake 基因改造方案。

一、分庫(kù)分表核心策略與時(shí)機(jī)

1.1 什么時(shí)候必須分庫(kù)分表?

觸發(fā)條件

  • 單表行數(shù):> 5000萬(wàn)行(B+樹深度增加導(dǎo)致隨機(jī)I/O劇增)
  • 單表大小:> 200GB(備份時(shí)間窗口>6小時(shí))
  • 寫并發(fā):> 5000 QPS(主從延遲>15分鐘)
  • 查詢耗時(shí):簡(jiǎn)單查詢>1秒

架構(gòu)演進(jìn)路徑

  1. 垂直分庫(kù):按業(yè)務(wù)拆分(用戶庫(kù)、訂單庫(kù)),解決耦合問(wèn)題
  2. 垂直分表:大字段拆分到擴(kuò)展表,單表體積減少60%
  3. 水平分表:?jiǎn)螏?kù)內(nèi)分表,緩解單表壓力
  4. 水平分庫(kù):跨實(shí)例分片,支撐億級(jí)數(shù)據(jù)

1.2 分片類型對(duì)比

分片類型拆分維度優(yōu)點(diǎn)缺點(diǎn)適用場(chǎng)景
垂直分庫(kù)業(yè)務(wù)模塊業(yè)務(wù)清晰,隔離故障跨庫(kù)事務(wù)復(fù)雜微服務(wù)化改造
垂直分表字段冷熱減少單表大小,提升緩存命中率增加 JOIN 查詢大字段(text/blob)分離
水平分表行數(shù)據(jù)單庫(kù)內(nèi)優(yōu)化,無(wú)分布式事務(wù)無(wú)法突破單庫(kù)性能瓶頸數(shù)據(jù)量<5000萬(wàn)
水平分庫(kù)行數(shù)據(jù)無(wú)限擴(kuò)展,支撐 PB 級(jí)數(shù)據(jù)分片鍵設(shè)計(jì)復(fù)雜10億+訂單、日志場(chǎng)景

二、中間件選型:ShardingSphere vs Mycat vs ShardingCore

2.1 三大中間件核心能力對(duì)比

特性ShardingSphereMycatShardingCore
定位生態(tài)化平臺(tái)(JDBC + Proxy + Sidecar)獨(dú)立中間件(Proxy).NET 生態(tài)分片框架
架構(gòu)模式支持 JDBC 和 Proxy 混合部署僅 Proxy 模式僅 JDBC 模式
SQL 支持完整支持(子查詢、UNION、JOIN)部分支持(復(fù)雜 SQL 需優(yōu)化)完整支持(LINQ 集成)
分布式事務(wù)XA、Seata 柔性事務(wù)XA 弱事務(wù)依賴外部事務(wù)方案
數(shù)據(jù)遷移提供 Scaling 遷移工具手動(dòng)遷移為主支持運(yùn)行時(shí)動(dòng)態(tài)建表
社區(qū)活躍度Apache 頂級(jí)項(xiàng)目,持續(xù)更新社區(qū)維護(hù)放慢.NET 生態(tài)活躍
性能JDBC 模式性能損耗<3%網(wǎng)絡(luò)代理?yè)p耗 10-15%與原生 EF Core 持平
云原生支持 K8s Operator支持較弱需自建

選型建議

  • Java 生態(tài) + 復(fù)雜查詢:首選 ShardingSphere(功能最完整)
  • 遺留系統(tǒng) + 快速接入:考慮 Mycat(無(wú)需改代碼)
  • .NET 項(xiàng)目:必選 ShardingCore(無(wú)縫集成 EF Core)

2.2 ShardingSphere 架構(gòu)詳解

混合部署模式

# sharding-proxy 配置示例(透明代理)
schemaName: order_db
dataSources:
  ds_0: { url: jdbc:mysql://db0:3306/order_db0, ... }
  ds_1: { url: jdbc:mysql://db1:3306/order_db1, ... }
rules:
  - !SHARDING
    tables:
      orders:
        actualDataNodes: ds_${0..1}.orders_${0..15}
        tableStrategy:
          standard:
            shardingColumn: order_id
            shardingAlgorithmName: gene_hash
shardingAlgorithms:
  gene_hash:
    type: CLASS_BASED
    props:
      strategy: standard
      algorithmClassName: com.example.GeneShardingAlgorithm

JDBC 模式優(yōu)勢(shì):應(yīng)用直連數(shù)據(jù)庫(kù),無(wú)網(wǎng)絡(luò)代理?yè)p耗,性能接近原生 SQL。

2.3 Mycat 快速接入

核心配置(schema.xml):

<schema name="order_db" checkSQLschema="true">
    <table name="orders" dataNode="dn$0-15" rule="mod-long" />
</schema>
<dataNode name="dn0" dataHost="dh0" database="order_db0" />
<dataNode name="dn1" dataHost="dh0" database="order_db1" />
<dataHost name="dh0" balance="1" writeType="0" dbType="mysql">
    <writeHost host="hostM1" url="db0:3306" user="root" password="xxx"/>
    <readHost host="hostS1" url="db1:3306" user="root" password="xxx"/>
</dataHost>

適用場(chǎng)景:遺留系統(tǒng)無(wú)法修改代碼時(shí),通過(guò) Mycat 透明代理實(shí)現(xiàn)分片。

三、分片鍵選擇:架構(gòu)設(shè)計(jì)的關(guān)鍵戰(zhàn)役

3.1 分片鍵選擇三原則

原則1:離散性(避免數(shù)據(jù)熱點(diǎn))

-- 錯(cuò)誤:status 只有 3 個(gè)值,導(dǎo)致 3 個(gè)分片成為熱點(diǎn)
PARTITION BY HASH(status) PARTITIONS 64; -- 只有 3 個(gè)分區(qū)有數(shù)據(jù)
-- 正確:user_id 哈希,數(shù)據(jù)均勻分布
PARTITION BY HASH(user_id) PARTITIONS 64;

原則2:業(yè)務(wù)相關(guān)性(80%查詢需攜帶)

訂單系統(tǒng)高頻查詢:
1. 用戶查歷史訂單 → 必須帶 user_id ?
2. 商家查訂單 → 必須帶 merchant_id ?
3. 客服按訂單號(hào)查 → 必須帶 order_no ?
分片鍵選擇:user_id(覆蓋場(chǎng)景最多)

原則3:穩(wěn)定性(值不隨業(yè)務(wù)變更)

-- 錯(cuò)誤:手機(jī)號(hào)可能變更,導(dǎo)致數(shù)據(jù)遷移
-- 正確:user_id 是主鍵,永不改變

3.2 高級(jí)分片策略

基因分片:訂單系統(tǒng)的終極方案

問(wèn)題:訂單系統(tǒng)有三大查詢維度(user_id, merchant_id, order_no),如何保證每個(gè)維度都能快速定位分片?

解決方案:將 user_id 基因嵌入訂單號(hào)中

Snowflake 改造

// 64位ID結(jié)構(gòu):符號(hào)位(1) + 時(shí)間戳(41) + 分片基因(12) + 序列號(hào)(10)
public class OrderIdGenerator {
    private static final int GENE_BITS = 12; // 12位基因支持4096個(gè)分片
    public static long generateId(long userId) {
        long timestamp = System.currentTimeMillis() - 1288834974657L;
        long gene = userId & ((1 << GENE_BITS) - 1); // 提取user_id后12位作為基因
        long sequence = getNextSequence();
        return (timestamp << 22) | (gene << 10) | sequence;
    }
    // 從訂單ID反推分片位置
    public static int getShardKey(long orderId) {
        return (int) ((orderId >> 10) & 0xFFF); // 提取中間12位基因
    }
}

路由邏輯

public class OrderShardingRouter {
    private static final int DB_COUNT = 8;          // 8個(gè)庫(kù)
    private static final int TABLE_COUNT = 16;      // 每庫(kù)16張表
    public static String route(long orderId) {
        int gene = OrderIdGenerator.getShardKey(orderId);
        int dbIndex = gene % DB_COUNT;              // 基因決定庫(kù)
        int tableIndex = gene % TABLE_COUNT;        // 基因決定表
        return String.format("order_db_%d.orders_%d", dbIndex, tableIndex);
    }
}

突破點(diǎn)

  • ? 用戶查詢:用 user_id 直接定位分片
  • ? 訂單號(hào)查詢:從 order_id 提取基因定位分片
  • ? 數(shù)據(jù)均勻:user_id 后12位哈希分布隨機(jī),避免熱點(diǎn)
一致性哈希:平滑擴(kuò)容方案

傳統(tǒng)取模問(wèn)題user_id % 8 擴(kuò)容到 16 時(shí),87.5% 數(shù)據(jù)需遷移。

一致性哈希:將哈??臻g虛擬為 2^32 個(gè)節(jié)點(diǎn),數(shù)據(jù)映射到虛擬節(jié)點(diǎn),擴(kuò)容時(shí)僅遷移相鄰節(jié)點(diǎn)數(shù)據(jù)

實(shí)現(xiàn)框架

// 使用 Ketama 算法
public class ConsistentHashSharding {
    private final SortedMap<Long, String> circle = new TreeMap<>();
    public void addServer(String server) {
        for (int i = 0; i < 160; i++) { // 160個(gè)虛擬節(jié)點(diǎn)
            circle.put(hash(server + "-" + i), server);
        }
    }
    public String getServer(Long key) {
        if (circle.isEmpty()) return null;
        long hash = hash(key);
        SortedMap<Long, String> tailMap = circle.tailMap(hash);
        hash = tailMap.isEmpty() ? circle.firstKey() : tailMap.firstKey();
        return circle.get(hash);
    }
}

四、全局ID生成:Snowflake 基因注入方案

4.1 Snowflake 標(biāo)準(zhǔn)結(jié)構(gòu)

64位ID組成

位段分布:
0-0   : 符號(hào)位(1位,始終為0)
1-41  : 時(shí)間戳(41位,支持69年,從2020起算)
42-52 : 機(jī)器ID(10位,支持1024個(gè)節(jié)點(diǎn))
53-63 : 序列號(hào)(12位,每毫秒4096個(gè)ID)

問(wèn)題:標(biāo)準(zhǔn) Snowflake 無(wú)法攜帶分片基因,路由需查詢映射表。

4.2 基因注入改造

改造后結(jié)構(gòu)

0-0   : 符號(hào)位(1位)
1-41  : 時(shí)間戳(41位)- 支持到 2089年
42-53 : 分片基因(12位)- 支持4096個(gè)分片
54-63 : 序列號(hào)(10位)- 每毫秒1024個(gè)ID

Java 實(shí)現(xiàn)

public class GeneSnowflake {
    private final long twepoch = 1288834974657L; // 起始時(shí)間戳
    private final long geneBits = 12L;           // 基因位數(shù)
    private final long sequenceBits = 10L;       // 序列號(hào)位數(shù)
    private final long geneShift = sequenceBits; // 基因左移10位
    private final long timestampShift = geneBits + sequenceBits; // 時(shí)間戳左移22位
    public synchronized long nextId(long userId) {
        long timestamp = System.currentTimeMillis();
        long gene = userId & ((1 << geneBits) - 1); // 提取基因
        long sequence = getSequenceInSameMs(timestamp); // 毫秒內(nèi)序列號(hào)
        return ((timestamp - twepoch) << timestampShift) |
               (gene << geneShift) |
               sequence;
    }
}

性能指標(biāo)

  • 生成速度:?jiǎn)喂?jié)點(diǎn) > 10萬(wàn) ID/秒
  • 趨勢(shì)遞增:時(shí)間戳高位,保證數(shù)據(jù)庫(kù)寫入性能
  • 零依賴:無(wú)需 Redis、DB,純內(nèi)存生成

4.3 ID 反解與分片定位

從 order_id 提取路由信息

// 提取基因(分片鍵)
public static int extractGene(long orderId) {
    // 基因位于第10-21位:orderId >> 10 & 0xFFF
    return (int) ((orderId >> 10) & 0xFFF);
}
// 提取生成時(shí)間
public static Date extractTime(long orderId) {
    long timestamp = (orderId >> 22) + twepoch;
    return new Date(timestamp);
}
// 完整路由示例
public class OrderService {
    public Order getOrderById(long orderId) {
        int gene = extractGene(orderId);
        String dbTable = OrderShardingRouter.routeByGene(gene);
        return executeQuery("SELECT * FROM " + dbTable + " WHERE order_id = ?", orderId);
    }
}

五、跨分片查詢:三大解決方案

5.1 異構(gòu)索引表(最常用)

方案:在 Elasticsearch 中建立二級(jí)索引,存儲(chǔ)分片路由信息

ES 索引結(jié)構(gòu)

{
  "order_index": {
    "mappings": {
      "properties": {
        "order_no": { "type": "keyword" },
        "shard_key": { "type": "integer" },  // 分片基因
        "user_id": { "type": "long" },
        "merchant_id": { "type": "long" }
      }
    }
  }
}

查詢流程

// 商家查詢訂單(先查ES定位分片)
public List<Order> getOrdersByMerchant(Long merchantId) {
    // 1. ES 中查詢 shard_key
    SearchResponse response = esClient.search(
        new SearchRequest("order_index")
            .source(new SearchSourceBuilder()
                .query(QueryBuilders.termQuery("merchant_id", merchantId))
                .fetchField("shard_key")
                .size(10000))
    );
    // 2. 按 shard_key 分組
    Map<Integer, List<Long>> shardGroups = groupByShard(response);
    // 3. 并發(fā)查詢各分片
    return shardGroups.entrySet().parallelStream()
        .map(entry -> queryShard(entry.getKey(), entry.getValue()))
        .flatMap(List::stream)
        .collect(Collectors.toList());
}

5.2 全局二級(jí)索引(GSI)

ShardingSphere 實(shí)現(xiàn)

-- 創(chuàng)建全局索引(自動(dòng)同步到指定存儲(chǔ)節(jié)點(diǎn))
CREATE SHARDING GLOBAL INDEX idx_merchant ON orders(merchant_id)
    BY SHARDING_ALGORITHM(merchant_hash)
    WITH STORAGE_UNIT(ds_0, ds_1);
-- 查詢時(shí)自動(dòng)路由
SELECT * FROM orders WHERE merchant_id = 10086;
-- ShardingSphere 自動(dòng)改寫為:先查 GSI 表獲取 order_id,再路由到主表

適用場(chǎng)景:低頻但強(qiáng)一致性的跨分片查詢

5.3 CQRS 模式:讀寫分離

架構(gòu)設(shè)計(jì)

寫操作(Command):
  應(yīng)用服務(wù) → 分片路由 → 寫入分片庫(kù)
讀操作(Query):
  應(yīng)用服務(wù) → ES/HBase → 聚合結(jié)果

優(yōu)勢(shì)

  • 寫操作保持分片優(yōu)勢(shì)
  • 讀操作通過(guò) ES 實(shí)現(xiàn)全文檢索、聚合
  • 避免跨分片 JOIN

六、數(shù)據(jù)遷移:雙寫方案與灰度切換

6.1 雙寫架構(gòu)

遷移期架構(gòu)

雙寫偽代碼

public void createOrder(Order order) {
    try {
        // 1. 寫新庫(kù)(主庫(kù))
        orderNewDao.insert(order);
        // 2. 寫舊庫(kù)(備份)
        orderOldDao.insert(order);
    } catch (Exception e) {
        // 3. 新庫(kù)失敗必須回滾舊庫(kù)
        if (isNewSuccess()) {
            orderNewDao.delete(order.getId());
        }
        throw e;
    }
}

關(guān)鍵原則

  • 新庫(kù)優(yōu)先:主寫新庫(kù),成功后再寫舊庫(kù)
  • 失敗回滾:新庫(kù)失敗需刪除舊庫(kù)數(shù)據(jù),保證最終一致性
  • 監(jiān)控告警:雙寫延遲>1秒觸發(fā)告警

6.2 灰度切換四階段

階段操作流量比例回滾策略
1. 雙寫階段新舊庫(kù)同時(shí)寫入0%可隨時(shí)切回舊庫(kù)
2. 全量遷移歷史數(shù)據(jù)分批導(dǎo)入0%校驗(yàn)收據(jù)
3. 增量驗(yàn)證實(shí)時(shí)比對(duì)數(shù)據(jù)一致性0%自動(dòng)修復(fù)不一致
4. 灰度引流按用戶ID百分比切換1% → 50% → 100%發(fā)現(xiàn)問(wèn)題立即回滾

切換命令

// 動(dòng)態(tài)分片路由(按用戶ID灰度)
public String routeByUserId(Long userId) {
    if (userId <= 10000) { // 1%用戶切新庫(kù)
        return "order_new";
    } else {
        return "order_old";
    }
}

七、避坑指南與性能陷阱

7.1 熱點(diǎn)數(shù)據(jù)分片傾斜

現(xiàn)象:某網(wǎng)紅店鋪訂單全部分到同一分片,導(dǎo)致該分片成為熱點(diǎn)

根因merchant_id 哈希不均,大商家數(shù)據(jù)量占 30%

解決方案

-- 復(fù)合分片鍵:(merchant_id + user_id) % 1024
-- 路由邏輯:將大商家數(shù)據(jù)按 user_id 二次打散
public int getShardKey(long merchantId, long userId) {
    if (isBigMerchant(merchantId)) {
        return (int) ((merchantId * 31 + userId) % 1024);
    } else {
        return (int) (merchantId % 1024);
    }
}

7.2 分布式事務(wù):最終一致性方案

問(wèn)題:跨庫(kù)事務(wù)無(wú)法使用本地 ACID

RocketMQ 最終一致性

@Transactional
public void createOrder(Order order) {
    // 1. 本地事務(wù):寫訂單主庫(kù)
    orderDao.insert(order);
    // 2. 發(fā)送事務(wù)消息(半消息)
    TransactionSendResult result = rocketMQTemplate.sendMessageInTransaction(
        "order_create_event",
        MessageBuilder.withPayload(order.toJson()).build(),
        null
    );
    // 3. 消息確認(rèn)后,下游消費(fèi)加積分、扣庫(kù)存
}
// 消費(fèi)者異步處理
@RocketMQMessageListener(topic = "order_create_event")
public void handleEvent(OrderEvent event) {
    bonusService.addPoints(event.getUserId());      // 異步加積分
    inventoryService.deduct(event.getSkuId());      // 異步扣庫(kù)存
}

優(yōu)勢(shì):避免分布式鎖,吞吐量提升 10 倍

7.3 跨分片分頁(yè)陷阱

現(xiàn)象LIMIT 100, 10 跨分片查詢需掃描所有分片,內(nèi)存聚合后排序,性能極差

解決方案

-- 方案1:業(yè)務(wù)折衷(禁用深分頁(yè),僅支持前100頁(yè))
-- 方案2:ES 聚合查詢(推薦)
GET /order_index/_search
{
  "from": 100,
  "size": 10,
  "sort": [{"create_time": "desc"}]
}
-- 方案3:游標(biāo)分頁(yè)(記錄上次查詢的 order_id)
SELECT * FROM orders 
WHERE create_time < '2024-01-01' AND order_id < #{lastOrderId}
ORDER BY create_time DESC LIMIT 10;

八、性能指標(biāo)與架構(gòu)演進(jìn)

8.1 拆分前后性能對(duì)比

場(chǎng)景拆分前拆分后提升倍數(shù)
用戶訂單查詢3200ms68ms47倍
商家訂單導(dǎo)出超時(shí)失敗8秒可用
全表統(tǒng)計(jì)不可用1.2秒(近似)可用
寫入并發(fā)2000 QPS8000 QPS4倍

8.2 分庫(kù)分表架構(gòu)最佳實(shí)踐

1. 分片鍵選擇大于努力

// 基因分片是訂單系統(tǒng)的最佳拍檔
// 12位基因支持 4096 個(gè)分片 = 8庫(kù) × 16表 × 32冗余

2. 預(yù)留擴(kuò)容空間

-- 初始設(shè)計(jì):8庫(kù) × 16表 = 128分片
-- 支持單分片 500萬(wàn)行 → 總?cè)萘?6.4億行
-- 預(yù)留 2 年數(shù)據(jù)增長(zhǎng)

3. 避免過(guò)度設(shè)計(jì)

// 小表(<1000萬(wàn)行)無(wú)需分片
// 大表關(guān)聯(lián)查詢:優(yōu)先冗余字段,避免跨分片 JOIN

4. 監(jiān)控驅(qū)動(dòng)優(yōu)化

-- 監(jiān)控分片傾斜率
SELECT db, table_name, COUNT(*) AS rows 
FROM information_schema.tables 
WHERE table_schema LIKE 'order_db_%' 
GROUP BY db, table_name 
HAVING rows > AVG(rows) * 1.5; -- 找出超平均分片50%的熱點(diǎn)

8.3 終極架構(gòu)方案

核心分層

  • 路由層:ShardingSphere 負(fù)責(zé)分片
  • 索引層:ES 處理跨分片查詢
  • 消息層:RocketMQ 保證最終一致性
  • 歸檔層:歷史數(shù)據(jù)遷移至 OSS

總結(jié)

決策點(diǎn)推薦方案避免方案
分片鍵user_id + 基因注入手機(jī)號(hào)、狀態(tài)碼
中間價(jià)ShardingSphere (Java)自研(成本高)
全局IDSnowflake 基因改造UUID(無(wú)序)
跨分片查詢ES 異構(gòu)索引跨庫(kù) JOIN
數(shù)據(jù)遷移雙寫 + 灰度停機(jī)遷移
分布式事務(wù)最終一致性(MQ)XA(性能差)

黃金法則:分庫(kù)分表不是架構(gòu)的終點(diǎn),而是數(shù)據(jù)治理的起點(diǎn)。真正的架構(gòu)藝術(shù),是在分與合之間找到平衡點(diǎn),通過(guò)基因分片實(shí)現(xiàn)數(shù)據(jù)自治,通過(guò) ES 索引實(shí)現(xiàn)查詢自由,通過(guò) MQ 實(shí)現(xiàn)事務(wù)自由,最終支撐從 10億 到 100億 的平滑演進(jìn)。

到此這篇關(guān)于MySql分庫(kù)分表深度指南之從策略到落地的文章就介紹到這了,更多相關(guān)mysql分庫(kù)分表內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!

相關(guān)文章

  • MySQL InnoDB之事務(wù)與鎖詳解

    MySQL InnoDB之事務(wù)與鎖詳解

    MySQL InnoDB之事務(wù)與鎖詳解,需要使用事務(wù)的朋友可以參考下
    2012-04-04
  • 詳解SQL四種語(yǔ)言:DDL DML DCL TCL

    詳解SQL四種語(yǔ)言:DDL DML DCL TCL

    本文詳細(xì)介紹了sql的四種語(yǔ)言,包括數(shù)據(jù)定義語(yǔ)言(DDL)、數(shù)據(jù)操作語(yǔ)言(DML)、數(shù)據(jù)控制語(yǔ)言(DCL)和事物控制語(yǔ)言(TCL)。在這幾種語(yǔ)言中有疑惑的可以來(lái)看看這篇文章。
    2016-07-07
  • MySQL?索引結(jié)構(gòu)、對(duì)比與操作實(shí)踐詳細(xì)攻略

    MySQL?索引結(jié)構(gòu)、對(duì)比與操作實(shí)踐詳細(xì)攻略

    在MySQL數(shù)據(jù)庫(kù)中索引是特殊的數(shù)據(jù)結(jié)構(gòu),它與表中數(shù)據(jù)關(guān)聯(lián),就像書籍的目錄與正文的關(guān)系目錄通過(guò)章節(jié)標(biāo)題和頁(yè)碼快速定位內(nèi)容,而索引則通過(guò)存儲(chǔ)數(shù)據(jù)的關(guān)鍵列值及其對(duì)應(yīng)物理位置,幫助數(shù)據(jù)庫(kù)快速定位目標(biāo)數(shù)據(jù),本文介紹MySQL索引結(jié)構(gòu)、對(duì)比與操作,感興趣的朋友一起看看吧
    2025-10-10
  • 在MySQL字段中使用逗號(hào)分隔符的方法分享

    在MySQL字段中使用逗號(hào)分隔符的方法分享

    大多數(shù)開發(fā)者應(yīng)該都遇到過(guò)在mysql字段中存儲(chǔ)逗號(hào)分割字符串的經(jīng)歷,無(wú)論這些被分割的字段代表的是id還是tag,這個(gè)字段都應(yīng)該具有如下幾個(gè)共性
    2012-06-06
  • mysql數(shù)據(jù)庫(kù)忘記管理員密碼的解決方法

    mysql數(shù)據(jù)庫(kù)忘記管理員密碼的解決方法

    我們?cè)赪indows操作系統(tǒng)下編程會(huì)使用到MySQL數(shù)據(jù)庫(kù)。但是有時(shí),我們會(huì)忘記數(shù)據(jù)庫(kù)的登錄密碼?當(dāng)我們忘記了登錄密碼,無(wú)法進(jìn)入mysql時(shí),該怎么辦呢?這里我們提供mysql的登錄秘密的修改
    2018-02-02
  • MySQL死鎖檢查處理的正常方法

    MySQL死鎖檢查處理的正常方法

    這篇文章主要給大家介紹了關(guān)于MySQL死鎖檢查處理的正常方法,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧
    2020-10-10
  • MySQL啟動(dòng)報(bào)錯(cuò)問(wèn)題InnoDB:Unable to lock/ibdata1 error

    MySQL啟動(dòng)報(bào)錯(cuò)問(wèn)題InnoDB:Unable to lock/ibdata1 error

    這篇文章主要介紹了MySQL啟動(dòng)報(bào)錯(cuò)問(wèn)題InnoDB:Unable to lock/ibdata1 error,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下
    2019-07-07
  • 如何使用MySQL查詢一年中每月的記錄數(shù)

    如何使用MySQL查詢一年中每月的記錄數(shù)

    這篇文章主要給大家介紹了關(guān)于如何使用MySQL查詢一年中每月的記錄數(shù)的相關(guān)資料,文中通過(guò)實(shí)例代碼以及圖文介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下
    2022-09-09
  • MYSQL如何 查詢數(shù)據(jù)庫(kù)中所有表中的數(shù)據(jù)量

    MYSQL如何 查詢數(shù)據(jù)庫(kù)中所有表中的數(shù)據(jù)量

    INFORMATION_SCHEMA.TABLES 是 MySQL 中的系統(tǒng)表,用于存儲(chǔ)關(guān)于數(shù)據(jù)庫(kù)中的表的信息,這篇文章主要介紹了MYSQL如何 查詢數(shù)據(jù)庫(kù)中所有表中的數(shù)據(jù)量,需要的朋友可以參考下
    2024-01-01
  • MySQL連接指定端口后實(shí)際仍是3306的原因分析及解決方法

    MySQL連接指定端口后實(shí)際仍是3306的原因分析及解決方法

    在日常運(yùn)維或開發(fā)過(guò)程中,有時(shí)我們?cè)谑褂?nbsp;mysql 命令行工具連接 MySQL 實(shí)例時(shí),可能會(huì)遇到一個(gè)令人疑惑的問(wèn)題,本以為連接的是監(jiān)聽(tīng)在 3307 端口的 MySQL 實(shí)例,但登錄進(jìn)去后執(zhí)行,實(shí)際連接的是3306 端口,而不是我們指定的端口,這是為什么?本文將為你詳細(xì)解答
    2025-07-07

最新評(píng)論

莱阳市| 定结县| 辛集市| 鄂尔多斯市| 文水县| 水富县| 巴林左旗| 平顺县| 太仆寺旗| 岗巴县| 乌鲁木齐县| 黄大仙区| 仁布县| 斗六市| 道孚县| 孝感市| 白银市| 无为县| 左云县| 永吉县| 通化县| 东乡县| 贵德县| 大丰市| 华宁县| 海林市| 西华县| 琼中| 德安县| 大英县| 镶黄旗| 双峰县| 永和县| 栾城县| 宜阳县| 镇原县| 山阴县| 宁乡县| 青岛市| 师宗县| 宁河县|