mysql 帐号余额和消费记录表设计？

余额可以单独用一个余额记录表，这样如果要查询每次消费记录的时候，也能查出来每次消费后还有多少余额。余额记录表里面主要是三个字段：用户账号、每次消费后的余额、时间点。

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)

mysql数据库超过并发量会pengding mysql数据库超过并发量会

主要是针对数据量很大，和并发访问量高的时候

经验一:

在开发过程中，我们经常会写

SELECT * FROM table WHERE 1 ORDER BY xxx DESC LIMIT 0,10

这样的语句用来分页

在有完美索引的情况 对xxx建立索引

前面几页会很快，但如果数据量达到100万级以后，我们查询最后一页

SELECT * FROM table WHERE 1 ORDER BY xxx DESC LIMIT 999990,10

这句执行就会很慢，同时有多人访问服务器就会掉 (这里不考虑缓存，因为内容更新太快，有时候缓存了达不到数据的更新的要求)

但如果我们把

SELECT * FROM table WHERE 1 ORDER BY xxx DESC LIMIT 999990,10

换成

SELECT * FROM table WHERE 1 ORDER BY xxx ASC LIMIT 0,10

这两个的MYSQL执行时间可是大大的不一样 当然要注意把这样取出来的结果用PHP重新排序一下

取得的一样是最后一页的数据，当然最中间的两页有部分数据一样

这时候最慢的只是最中间的部分，相对而言，访问最中间的人还是很少的

经验二:

例如论坛帖子列表的显示:

一般是SELECT * FROM table ORDER BY is_top DESC ,post_time DESC LIMIT 0,10这样的分页

两个order by 的执行是非常慢的，哪怕你有再好的索引，

我们的处理办法是 把is_top的数据CACHE住，毕竟is_top的数据量有限，更新这个缓存也容易

然后SQL一样是SELECT * FROM table ORDER BY post_time DESC LIMIT {$num},{$num2}

注意这个$num2 是减掉is_top的数量后的一个值,$num是is_top的数量

当然还要考虑is_top的数据量是不是有好几页,当前页的值是不是都在cache里面

经验三:

SELECT * FROM table ORDER BY RAND() LIMIT 100 这个ORDER BY RAND() 是非常慢的 能不用尽量不要用

处理办法是

1.用PHP生成数组后，然后用SELECT * FROM table WHERE id IN() WHERE IN 也比这个order by rand()快的多

2.如果数量信息不太重多，就用SELECT * FROM table WHERE 1 LIMIT 500 多取点数据，然后用php 处理数组

我理解的是：读表的锁表是指在读的过程中上锁，不允许中途还insert其他记录，当读表完毕，获得select结果后，表就解锁了，可以继续新的select或insert等 *** 作。

例子里：2人同时借钱，没有业务锁的话，两个请求发到后端后可能同时去select，此时2次借款 *** 作select余额都是1000（在另一人借200后回写余额800之前），于是2个请求 *** 作各自开始借钱，算出借钱后都剩下800，再分别update进表中，表里余额就是800

如果加业务锁：2个请求到后端后，select余额和借钱后Update按一个事务进行，那第1人select 1000元并借款后剩下800更新进表中，完成第1人借钱事务后，再进行第2人借钱select 剩下的800元并借款后剩下600更新进表中，就可以避免

---