注意事项：
- 索引不是越多越好，每个索引都会增加写入成本
- 避免在低区分度字段（如性别）建立索引
- 定期检查索引使用情况，删除无用索引

策略二：物化视图（Materialized Views）

核心思想： 预计算复杂查询结果，避免实时计算。

适用场景：
- 复杂的多表关联查询
- 聚合统计报表
- 数据量大但更新不频繁的场景

如何做：

-- 创建物化视图（PostgreSQL语法）
CREATE MATERIALIZED VIEW customer_orders AS
SELECT
    c.customer_id,
    c.customer_name,
    COUNT(o.order_id) as order_count,
    SUM(o.order_amount) as total_amount
FROM customers c
LEFT JOIN orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.customer_name;

-- 定期刷新物化视图
REFRESH MATERIALIZED VIEW customer_orders;

策略三：反规范化（Denormalization）

核心思想： 牺牲一定的数据冗余，换取查询性能的提升。

适用场景：
- 读多写少的场景
- 查询性能要求极高
- 可接受数据延迟一致

经典案例：
订单详情表将产品名称、客户名称等冗余存储，避免查询时频繁关联多表。

-- 反规范化后的订单表
CREATE TABLE customer_orders (
    id BIGINT PRIMARY KEY,
    product_name VARCHAR(100),  -- 冗余字段
    customer_name VARCHAR(100), -- 冗余字段
    order_id BIGINT,
    order_amount DECIMAL(10,2),
    created_at TIMESTAMP
);

策略四：垂直扩展（Vertical Scaling）

核心思想： 提升单台服务器的硬件配置。

具体做法：
- 升级CPU核心数
- 增加内存容量
- 使用更快的SSD存储
- 优化网络带宽

优势： 实施简单，无需修改应用代码
劣势： 单机存在性能上限，成本呈指数级增长

何时选择：
- 数据量在百万级别以下
- 预算充足但人力有限
- 快速解决燃眉之急

策略五：数据库缓存（Database Caching）

核心思想： 将热点数据存储在更快的存储层（如Redis）。

典型架构：

应用 → 缓存层(Redis) → 数据库
     ↓ 命中返回

实现示例：

# 伪代码：带缓存的查询
def getuserinfo(user_id):
    # 先查缓存
    cache_key = f"user:{user_id}"
    cacheddata = redis.get(cachekey)

    if cached_data:
        return json.loads(cached_data)

    # 缓存未命中，查数据库
    user_data = db.query("SELECT * FROM users WHERE id = %s", user_id)

    # 写入缓存
    redis.setex(cachekey, 3600, json.dumps(userdata))

    return user_data

写入 → 主数据库
       ↓ 同步
    ┌──┴──┐
  副本1  副本2  → 分担读取请求

# 伪代码：读写分离
def getorder(orderid):
    # 从副本读取
    return replicadb.query("SELECT * FROM orders WHERE id = %s", orderid)

def createorder(orderdata):
    # 写入主库
    return primarydb.execute("INSERT INTO orders ...", orderdata)

-- 订单表按user_id取模分片
orders_0  -- user_id % 10 = 0
orders_1  -- user_id % 10 = 1
orders_2  -- user_id % 10 = 2
...
orders_9  -- user_id % 10 = 9