1.事务不要大，太大一方面占用资源多，另外对资源加锁时间也长
2.合理的索引，使事务快速完成
3.表的字段和记录不要涉及多个业务，不同的业务使用不同的表
4.优化程序设计，将大的业务分解
简单的说：就是使并发操作对资源的使用降低到最小
B. 研究高并发量的SQL语句如何去优化
1、数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。
2、能够用数字类型的字段尽量选择数字类型而不用字符串类型的。
3、对于不可变字符类型char和可变字符类型varchar 都是8000字节,char查询快，但是耗存储空间，varchar查询相对慢一些但是节省存储空间。
4、字段的长度在最大限度的满足可能的需要的前提下，应该尽可能的设得短一些，这样可以提高查询的效率，而且在建立索引的时候也可以减少资源的消耗。
5、字段顺序对存储效率也有不小的影响。在做表结构设计的时候，我们往往不会去考虑字段的摆放顺序。但是，实际上字段的摆放顺序对数据库操作的性能是有影响的。
查询的优化
1、保证在实现功能的基础上，尽量减少对数据库的访问次数；
2、通过搜索参数，尽量减少对表的访问行数,最小化结果集，从而减轻网络负担；能够分开的操作尽量分开处理，提高每次的响应速度；
3、在数据窗口使用SQL时，尽量把使用的索引放在选择的首列；算法的结构尽量简单；
4、在查询时，不要过多地使用通配符如SELECT * FROM T1语句，要用到几列就选择几列如：SELECT COL1,COL2 FROM T1；
5、在可能的情况下尽量限制尽量结果集行数如：SELECT TOP 300 COL1,COL2,COL3 FROM T1,因为某些情况下用户是不需要那么多的数据的。
6、在没有建索引的情况下，数据库查找某一条数据，就必须进行全表扫描了，对所有数据进行一次遍历，查找出符合条件的记录。
7、在数据量比较小的情况下，也许看不出明显的差别，但是当数据量大的情况下，这种情况就是极为糟糕的了。
8、合理的使用临时表。例如表A 的 ID 字段有索引，并且这个表的数据有很多。这时候要查询这个ID 的最大值与最小值，如果能合理使用临时表，速度将大幅度提高！
9、多层的子查询需要进行简单化。
C. 如何优化大数据高并发量的系统的SQL语句提高效率
1. SQL优化的原则是：将一次操作需要读取的BLOCK数减到最低,即在最短的时间达到最大的数据吞吐量。 调整不良SQL通常可以从以下几点切入： ? 检查不良的SQL，考虑其写法是否还有可优化内容 ? 检查子查询 考虑SQL子查询是否可以用简单连接的方式进行重新书写 ? 检查优化索引的使用 ? 考虑数据库的优化器 2. 避免出现SELECT * FROM table 语句，要明确查出的字段。 3. 在一个SQL语句中，如果一个where条件过滤的数据库记录越多，定位越准确，则该where条件越应该前移。 4. 查询时尽可能使用索引覆盖。即对SELECT的字段建立复合索引，这样查询时只进行索引扫描，不读取数据块。 5. 在判断有无符合条件的记录时建议不要用SELECT COUNT （*）和select top 1 语句。 6. 使用内层限定原则，在拼写SQL语句时，将查询条件分解、分类，并尽量在SQL语句的最里层进行限定，以减少数据的处理量。 7. 应绝对避免在order by子句中使用表达式。 8. 如果需要从关联表读数据，关联的表一般不要超过7个。 9. 小心使用 IN 和 OR，需要注意In集合中的数据量。建议集合中的数据不超过200个。 10. <> 用 < 、 > 代替，>用>=代替，<用<=代替，这样可以有效的利用索引。 11. 在查询时尽量减少对多余数据的读取包括多余的列与多余的行。 12. 对于复合索引要注意，例如在建立复合索引时列的顺序是F1，F2，F3，则在where或order by子句中这些字段出现的顺序要与建立索引时的字段顺序一致，且必须包含第一列。只能是F1或F1，F2或F1，F2，F3。否则不会用到该索引。 13. 多表关联查询时，写法必须遵循以下原则，这样做有利于建立索引，提高查询效率。格式如下select sum（table1.je） from table1 table1, table2 table2, table3 table3 where (table1的等值条件（=）) and (table1的非等值条件) and (table2与table1的关联条件) and (table2的等值条件) and (table2的非等值条件) and (table3与table2的关联条件) and (table3的等值条件) and (table3的非等值条件)。 注:关于多表查询时from 后面表的出现顺序对效率的影响还有待研究。 14. 子查询问题。对于能用连接方式或者视图方式实现的功能，不要用子查询。例如：select name from customer where customer_id in ( select customer_id from order where money>1000)。应该用如下语句代替：select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。 15. 在WHERE 子句中，避免对列的四则运算，特别是where 条件的左边，严禁使用运算与函数对列进行处理。比如有些地方 substring 可以用like代替。 16. 如果在语句中有not in（in）操作，应考虑用not exists（exists）来重写,最好的办法是使用外连接实现。 17. 对一个业务过程的处理，应该使事物的开始与结束之间的时间间隔越短越好，原则上做到数据库的读操作在前面完成，数据库写操作在后面完成，避免交叉。 18. 请小心不要对过多的列使用列函数和order by,group by等，谨慎使用disti软件开发t。 19. 用union all 代替 union，数据库执行union操作，首先先分别执行union两端的查询，将其放在临时表中，然后在对其进行排序，过滤重复的记录。 当已知的业务逻辑决定query A和query B中不会有重复记录时，应该用union all代替union，以提高查询效率。 数据更新的效率 1. 在一个事物中，对同一个表的多个insert语句应该集中在一起执行。 2. 在一个业务过程中，尽量的使insert,update,delete语句在业务结束前执行，以减少死锁的可能性。 数据库物理规划的效率 为了避免I/O的冲突，我们在设计数据库物理规划时应该遵循几条基本的原则(以ORACLE举例)： table和index分离：table和index应该分别放在不同的tablespace中。 Rollback Segment的分离：Rollback Segment应该放在独立的Tablespace中。 System Tablespace的分离：System Tablespace中不允许放置任何用户的object。（mssql中primary filegroup中不允许放置任何用户的object） Temp Tablesace的分离：建立单独的Temp Tablespace，并为每个user指定default Temp Tablespace 避免碎片：但segment中出现大量的碎片时，会导致读数据时需要访问的block数量的增加。对经常发生DML操作的segemeng来说，碎片是不能完全避免的。所以，我们应该将经常做DML操作的表和很少发生变化的表分离在不同的Tablespace中。 当我们遵循了以上原则后，仍然发现有I/O冲突存在，我们可以用数据分离的方法来解决。 连接Table的分离：在实际应用中经常做连接查询的Table，可以将其分离在不同的Taclespace中，以减少I/O冲突。 使用分区：对数据量很大的Table和Index使用分区，放在不同的Tablespace中。 在实际的物理存储中，建议使用RAID。日志文件应放在单独的磁盘中。
D. 怎样解决sql server 数据库的并发问题
“sql server 数据库的并发问题”不如说是“数据库并发处理”问题。因为它不光是存在于SQL数据库上，几乎存在于任何数据库上。并发情况的处理一直是网络数据库编程需要面对和解决的，也往往是最花费时间和精力去对付的问题之一。这对于多数网络数据库编程新手来说，都是要碰到的一个问题。
就本人的经验给于以下提示：
1、对于容易出现并发问题的表，最好是一次性取出所需的数据，或部分数据，而不使用那些带缓冲的控件。
2、每次改写数据时，需要先读取要改写的记录进行校验。
3、尽可能少地对已存入表中的数据进行改写。可以用“删除”标志来作费原记录，新增改写后的记录。这样，每次操作都会“记录在案”，而不会无据可查。也规避了客户端改写时某条记录已发生了变化的情况发生。
4、每个表都需要拥有一个自动增量的字段，并设为主键，这样会减少SQL冲突的发生规避某些错误，而且会使数据库数据的查找加快（注意，在SQL2000中，如果一个表中存在两条完全一样的记录，将发生严重问题！比如两条空白记录）。
5、使用什么语言编程是无所谓的，重要的是注意设计上的控件。如当某个客户端上正在对某人员的信息进行处理时，别的客户端就不应该对该人员的信息进行处理。这可以引入占用机制，如客户端调入某人准备处理前先在表中标志占用标志和占用时刻……（具体的你自个去想吧）。
最后，希望给你说了这么多，你能看懂并好好运用它们。网络数据库编程技术上是不难的，最难的是考虑方方面面的因素。
E. 代码中并发执行同一个sql会影响sql的速度吗
对单次sql执行来讲，影响不会太大，除非并发数超过了数据库瓶颈，导致sql执行需要等待；
对整个并发执行来讲，肯定会比执行单个sql要慢的，因为虽然多次执行的sql是一样的，但是对数据库来讲还是需要进行多次处理的，只是在数据库中sql只需要解析
一次就好
F. SQLserver是怎么处理并发控制（同时有多个用户操作修改数据库中同一条记录）server和客户端分别如何处理
sqlserver
本身通过不同等级的锁处理并发控制。
有记录锁、页锁、表锁。
如果多个用户同时操作一个记录，只有第一个能修改，后面的修改时处理等等状态。
但是在一般程序界面上，多个人同时打开了同一个记录要进行修改，数据库往往是保存最后一个修改的数据。可以在保存前做验证，如果发现打开的数据已改变（界面和数据库一不致了），则提示数据已改变，重新获取新数据，然后才能修改和保存。
G. 代码中并发执行同一个sql会影响sql的速度吗
对单次sql执行来讲，影响不会太大，除非并发数超过了数据库瓶颈，导致sql执行需要等待；
对整个并发执行来讲，肯定会比执行单个sql要慢的，因为虽然多次执行的sql是一样的，但是对数据库来讲还是需要进行多次处理的，只是在数据库中sql只需要解析一次就好
H. 在SQL server 2005 数据库系统中，多用户同时操作数据库成为并发操作，那么在数据库系统上执行并发操作时
楼下说得对, 最小控制单元是:事务 一 事务的属性 事务具有ACID属性 即 Atomic原子性, Consistent一致性, Isolated隔离性, Durable永久性原子性就是事务应作为一个工作单元,事务处理完成，所有的工作要么都在数据库中保存下来，要么完全 回滚，全部不保留一致性事务完成或者撤销后，都应该处于一致的状态隔离性多个事务同时进行，它们之间应该互不干扰.应该防止一个事务处理其他事务也要修改的数据时， 不合理的存取和不完整的读取数据永久性事务提交以后，所做的工作就被永久的保存下来 二 事务并发处理会产生的问题丢失更新当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，会发生丢失更新问题、 每个事务都不知道其它事务的存在。最后的更新将重写由其它事务所做的更新，这将导致数据丢失。 脏读当第二个事务选择其它事务正在更新的行时，会发生未确认的相关性问题。 第二个事务正在读取的数据还没有确认并且可能由更新此行的事务所更改。 不可重复读当第二个事务多次访问同一行而且每次读取不同的数据时，会发生不一致的分析问题。 不一致的分析与未确认的相关性类似，因为其它事务也是正在更改第二个事务正在读取的数据。 然而，在不一致的分析中，第二个事务读取的数据是由已进行了更改的事务提交的。而且，不一致的分析涉及多次（两次或更多）读取同一行，而且每次信息都由其它事务更改；因而该行被非重复读取。 幻像读当对某行执行插入或删除操作，而该行属于某个事务正在读取的行的范围时，会发生幻像读问题。 事务第一次读的行范围显示出其中一行已不复存在于第二次读或后续读中，因为该行已被其它事务删除。同样，由于其它事务的插入操作，事务的第二次或后续读显示有一行已不存在于原始读中。 三 事务处理类型 自动处理事务 系统默认每个T－SQL命令都是事务处理 由系统自动开始并提交隐式事务当有大量的DDL 和DML命令执行时会自动开始，并一直保持到用户明确提交为止，切换隐式事务可以用SET IMPLICIT_TRANSACTIONS 为连接设置隐性事务模式.当设置为 ON 时，SET IMPLICIT_TRANSACTIONS 将连接设置为隐性事务模式。当设置为 OFF 时，则使连接返回到自动提交事务模式 用户定义事务 由用户来控制事务的开始和结束 命令有: begin tran commit tran rollback tran 命令分布式事务跨越多个服务器的事务称为分布式事务,sql server 可以由DTc microsoft distributed transaction coordinator 来支持处理分布式事务,可以使用 BEgin distributed transaction 命令启动一个分布式事务处理
I. SQL 事务并发问题处理 都进来看看
确保你的事务的第一句是update对应A表记录的语句，就算此时不马上把票数-1，也要确保随便update一个字段（更新成原值也可以），这样就保证了事务第一步已经给表此记录上了行锁，并发时，只要当前事务没走完，其他用户操作同条记录的操作都处于等待中不能执行，就不会发生并发出现负数的情况
这个是类似项目数据库端比较通用的解决并发问题的方法
不过你的执行时间如果是10秒太久了，至少要控制到一秒吧，高并发下，这样10秒会出问题的