楼上说的办法可行，但这个问题也不是那么简单。既然是选课，必定有n个人都在选（我们学校就提供几百台机器同时选课），现在加入一个字段记录该题目有多少人选，可能出现如下问题：甲、乙同时点了选A题目的按钮，查询时发现A题目共有3人选择，然后就把甲乙都增加上去，然后都改成4，实际上是5个人选了。这种现象在数据库中叫做“丢失修改”，估计你也学过了。 解决办法是再增加一个时间戳字段(timestamp类型)，这种类型不是一个时间，而是一个二进制数据，但每次修改这个字段的值都会变化。查人数时，要把人数字段和时间戳字段都查出来，而更新时，则以时间戳为条件，即Update xx Set 人数=人数+1 where 题目ID=A and 时间戳=查询人数时取出的时间戳。假设甲乙都查出人数3，时间戳x，但甲修改后，人数变为4，而时间戳自动变为y，那么乙再执行这个语句，影响的行数为0（后面条件不成立了），说明产生了丢失修改问题，这样就回滚，让乙的操作失效。 我校某招生考试报名系统中曾出现这种丢失修改的问题，后来我用这个方法解决了，呵呵，幸亏偶是教数据库的。
解决办法是再增加一个时间戳字段(timestamp类型)，这种类型不是一个时间，而是一个二进制数据，但每次修改这个字段的值都会变化。查人数时，要把人数字段和时间戳字段都查出来，而更新时，则以时间戳为条件，即Update xx Set 人数=人数+1 where 题目ID=A and 时间戳=查询人数时取出的时间戳。假设甲乙都查出人数3，时间戳x，但甲修改后，人数变为4，而时间戳自动变为y，那么乙再执行这个语句，影响的行数为0（后面条件不成立了），说明产生了丢失修改问题，这样就回滚，让乙的操作失效。
我校某招生考试报名系统中曾出现这种丢失修改的问题，后来我用这个方法解决了，呵呵，幸亏偶是教数据库的。