表结构必须区分收入与支出类型，不能只用一个 amount
字段加正负号
用正负号混存收支会导致后续统计异常：比如求「月度总支出」时得写
SUM(CASE WHEN amount ，既难读又易错。更关键的是，无法对收入/支出字段单独加约束（如支出不能为正）。实际做法是拆成两个非空字段：<code>income DECIMAL(12,2) DEFAULT 0和
expense DECIMAL(12,2) DEFAULT 0，并加检查约束：
CHECK ((income > 0 AND expense = 0) OR (income = 0 AND expense > 0) OR (income = 0 AND expense = 0))。这样还能配合应用层逻辑强制单向记账，避免手误填反。
transaction
表里必须有 category_id
和 subcategory_id
两级分类外键
只设一级分类（如“餐饮”“交通”）在后期分析时颗粒度太粗；全靠自由文本打标签又无法聚合统计。两级分类能兼顾灵活性和结构化：一级对应大类（
category表），二级对应具体场景（
subcategory表，如“外卖”“堂食”都属于“餐饮”）。注意
subcategory_id应设为
NULLABLE，因为部分收入项（如“工资”）可能不需要二级划分。建表时外键要明确指向各自主键，且启用
ON DELETE RESTRICT防止误删分类导致数据孤儿。
日期字段统一用 DATE
类型，别用 DATETIME
或字符串
财务统计几乎全是按日/月/年聚合，用
DATETIME多余且占空间；用字符串（如
'2024-05-20'）则丧失日期函数能力，连
WHERE date >= '2024-01-01'都可能因格式不一致失效。必须用
DATE，并配默认值：
date DATE NOT NULL DEFAULT (CURRENT_DATE)。如果需要记录录入时间（非发生时间），另加一个
created_at DATETIME DEFAULT CURRENT_TIMESTAMP字段即可——两者语义不同，不能混用。
余额不能实时计算，必须用 balance_snapshot
表定期快照
有人试图在查余额时用
SUM(income) - SUM(expense)实时算，这在数据量小、无并发写入时看似可行，但一旦有跨账户转账或补录历史账单，结果立刻错乱。正确做法是：每次新增/修改交易后，触发存储过程更新该账户最新余额，并每日零点自动插入一条
balance_snapshot记录，含
account_id、
snapshot_date、
balance。这样既能查任意时间点余额，又能验证账目连续性。快照表本身无需索引过多，但
(account_id, snapshot_date)联合索引必不可少。
