feat: settlement first api beta

docs/settlement/DESIGN.md

@@ -78,6 +78,7 @@ class DailySettlementConfig(ModelBase):
     class Meta:
         verbose_name = '日结配置'
         verbose_name_plural = '日结配置'
+        db_table = 'daily_settlement_config'
 ```
 
 **说明**：
@@ -212,8 +213,8 @@ def run_daily_settlement(self):
     from basic_info.models import Merchant
     
     # 获取所有配置了统计模块的商户
-    configs = DailySettlementConfig.objects.filter(
-        settlement_modules__len__gt=0
+    configs = DailySettlementConfig.objects.exclude(
+        settlement_modules=[]
     ).select_related('merchant')
     
     logger.info(
@@ -412,7 +413,42 @@ class SettlementConfig(AppConfig):
 3. 未来如需提升性能，可以通过增加 Celery worker 数量来解决
 4. Celery 本身支持任务队列和并发控制，后续可以轻松扩展
 
-## 十三、实施步骤
+## 十三、数据库优化评估（PostgreSQL）
+
+### 13.1 当前结论（暂不实施）
+
+已评估从数据库层面优化开版订单统计（索引、视图、物化视图），当前阶段暂不实施结构性优化，维持现有实现。
+
+### 13.2 暂缓原因
+
+1. 当前测试与功能已稳定，优先保证行为一致性
+2. 生产环境要求“不可接受阻塞风险”，索引变更需专项窗口与监控保障
+3. 现阶段数据规模下，统计查询尚可接受
+
+### 13.3 后续可选优化路线（按优先级）
+
+1. **索引优先**：为 `plate_order` 统计路径增加复合/部分索引
+2. **表达式索引**：针对 `date(plate_date)` 的筛选场景
+3. **物化视图**：当数据规模明显增大时，将日粒度聚合前置
+
+### 13.4 生产安全约束
+
+若后续执行索引优化，必须遵循：
+
+1. 使用 PostgreSQL `CREATE INDEX CONCURRENTLY`
+2. 迁移使用 `atomic = False`
+3. 低峰分批执行，一次一个索引
+4. 全程监控 CPU/IO/WAL、慢查询与复制延迟
+
+### 13.5 验证要求
+
+任何数据库优化上线前，需要在预发（接近生产数据量）完成：
+
+1. `EXPLAIN ANALYZE` 对比
+2. 回归测试通过（`settlement` + `api_v1.views.settlement`）
+3. 回滚脚本预演
+
+## 十四、实施步骤
 
 1. 创建 `settlement` 模块目录结构
 2. 实现 `models.py`（配置模型）
@@ -427,7 +463,7 @@ class SettlementConfig(AppConfig):
 11. 编写测试用例
 12. 手动触发测试，验证结果
 
-## 十四、方案优势
+## 十五、方案优势
 
 1. **独立模块**：`settlement` 模块独立，职责清晰
 2. **配置驱动**：每个商户可独立配置统计模块和通知渠道