余额可以单独用一个余额记录表，这样如果要查询每次消费记录的时候，也能查出来每次消费后还有多少余额。余额记录表里面主要是三个字段：用户账号、每次消费后的余额、时间点。
站在用户的角度思考问题，与客户深入沟通，找到巴中网站设计与巴中网站推广的解决方案，凭借多年的经验，让设计与互联网技术结合，创造个性化、用户体验好的作品，建站类型包括：成都网站建设、网站设计、企业官网、英文网站、手机端网站、网站推广、域名注册、虚拟主机、企业邮箱。业务覆盖巴中地区。
CREATE TABLE account
(
id integer NOT NULL DEFAULT nextval('trade_id_seq'::regclass),
no character varying(10) NOT NULL, -- 账号
balance money NOT NULL DEFAULT 0.00, -- 余额
datetime timestamp without time zone NOT NULL DEFAULT (now())::timestamp(0) without time zone,
CONSTRAINT account_pkey PRIMARY KEY (id)
)
通过每次的余额变化就知道每次消费后的余额情况
select acc.*, (select sum(balance)+acc.balance from account as ac where ac.id acc.id) as profit from account as acc;
id | no | balance | datetime | profit
----+------+----------+---------------------+---------
1 | 1000 | $0.00 | 2013-10-09 10:51:10 |
2 | 1000 | $12.60 | 2013-10-09 10:51:22 | $12.60
4 | 1000 | $16.80 | 2013-10-09 10:51:42 | $29.40
5 | 1000 | $100.00 | 2013-10-09 10:51:49 | $129.40
6 | 1000 | $200.00 | 2013-10-09 10:56:35 | $329.40
7 | 1000 | $50.45 | 2013-10-09 10:57:23 | $379.85
8 | 1000 | $75.50 | 2013-10-09 10:57:31 | $455.35
9 | 1000 | -$55.30 | 2013-10-09 10:59:28 | $400.05
10 | 1000 | -$200.00 | 2013-10-09 10:59:44 | $200.05
(9 rows)
网云数据后台可以直接连接数据库，上传数据库也很快
操作步骤
登录网云数据控制台-找到云虚拟主机-云虚拟主机管理。
选择想要重设数据库密码或数据库FTP密码的云虚拟主机，点击管理，进入虚拟主机的详情页。
进入数据库的详情页。
在基本信息栏点击修改数据库密码或数据库FTP密码。
输入新密码。
数据库升级、续费
数据库空间属于云虚拟主机赠送，如需对数据库进行升级或续费操作，请前往对应的云虚拟主机进行升级/续费。
在记录客户信息的表中加一个续费日期，记录这个用户在什么日期需要续费，在每次客户续费的时候update这个字段，比如周期30天，就把当天日期＋30后记录在里面，然后做个“查询续费日期”的页面，这个页面打开后，按续费日期order by排序，然后显示的时候把续费日期字段值－当前日期值，就可以显示出所有用户哪些需要续费了，哪些还剩多少时间.
单表一亿？还是全库1亿？
1.首先可以考虑业务层面优化，即垂直分表。
垂直分表就是把一个数据量很大的表,可以按某个字段的属性或使用频繁程度分类,拆分为多个表。
如有多种业务类型，每种业务类型入不同的表，table1,table2,table3.
如果日常业务不需要使用所有数据，可以按时间分表，比如说月表。每个表只存一个月记录。
2.架构上的优化，即水平分表。
水平分表就是根据一列或多列数据的值把数据行放到多个独立的表里，这里不具备业务意义。
如按照id分表，末尾是0-9的数据分别插入到10个表里面。
可能你要问，这样看起来和刚才说的垂直分表没什么区别。只不过是否具备业务意义的差异，都是按字段的值来分表。
实际上，水平分表现在最流行的实现方式，是通过水平分库来实现的。即刚才所说的10个表，分布在10个mysql数据库上。这样可以通过多个低配置主机整合起来，实现高性能。
最常见的解决方案是cobar，这个帖子介绍的比较完善，可以看看。
cobar的逻辑层次图：
不过这种分库方式也是有一定局限性的，需要应用程序做相应的配合，比如说分库的情况下，虽然可以实现跨库查询，但是不能进行相关的group by计算。
另外，之前关于水平分表的实现方式，也可以通过表分区来实现。
mysql优化的方式有很多，选择上主要还是要考虑个人的实际情况，如代码不可控的情况下，就不适合选择按字段属性分表的情况，这样可能会带来大量的重构以及很多不可预期的风险。
而架构的优化，虽然对应用是透明的，但对sql的写法有很多局限性，比如说不能使用聚合函数等等，同时也需要有充足的硬件资源，只有一台服务器的情况下是没有意义的。
相比起来，代价最低的是按时间分表或分区，这两种办法对应用来说都是透明的。
分区只需要一次本地数据迁移的操作。
而通过分表把现网数据和历史数据分离，唯一的代价是定期的数据维护。
一般如果表里面有1亿数据的情况下，索引的问题应该是常识了，这方面我就不说了。
另外如果觉得答的不错多给点分。
Log File物理结构
从 ib_logfile0和 ib_logfile1这两个文件的物理结构可以看出，在Log Header部分还是有些许差异的， ib_logfile0会多一些额外的信息，主要是checkpoint信息。
并且每个Block的单位是512字节，对应到磁盘每个扇区也是512字节，因此redo log写磁盘是原子写，保证能够写成功，而不像index page一样需要double write来保证安全写入。
我们依次从上到下来看每个Block的结构
Log File Header Block
Log Goup ID，可能会配置多个redo组，每个组对应一个id，当前都是0，占用4字节
Start LSN，这个redo log文件开始日志的lsn，占用8字节
Log File Number，总是为0，占用4字节
Created By，备份程序所占用的字节数，占用32字节
另外在ib_logfile0中会有两个checkpoint block，分别是 LOG_CHECKPOINT_1/ LOG_CHECKPOINT_2，两个记录InnoDB Checkpoint信息的字段，分别从文件头的第二个和第四个block开始记录，并且只在每组log的第一个文件中存在，组内其他文件虽然没有checkpoint相关信息，但是也会预留相应的空间出来。这里为什么有两个checkpoint的呢？原因是设计为交替写入，避免因为介质失败而导致无法找到可用的checkpoint的情况。
Log blocks
请点击输入图片描述
log block结构分为日志头段、日志记录、日志尾部
Block Header，占用12字节
Data部分
Block tailer，占用4字节
Block Header
这个部分是每个Block的头部，主要记录的块的信息
Block Number，表示这是第几个block，占用4字节，是通过LSN计算得来的，占用4字节
Block data len，表示该block中有多少字节已经被使用了，占用2字节
First Rec offet，表示该block中作为第一个新的mtr开始的偏移量，占用2字节
Checkpoint number，表示该log block最后被写入时的检查点的值，占用4字节
