用PB开发的一个数据库服务器多个异地客户端使用查询更新速度慢问题解决的技术方法

处理的方法很简单：

1、并不是所有的地方都需要使用read commit的加锁级别，你从application中设置一句sqlcalock="RU", 使用脏读，这样就可以去掉大多数不必要的SELECT行锁。然后在一定要读最新数据的地方，把SQLCA。LOCK改为RC，用完后再改回来。

这样就避免了几乎80%的阻塞。

2、对于由于行更新，或者其他UPDATE导致的锁，一般数据库会自己协调，在事务比较长的情况下，这需要你对原来的程序做适当的修改。把长事务变为几个小的事务，在事务中做更新 *** 作，不要插入用户的交互。这是系统的设计原则。

如果你的系统对事务的要求不严格，又不想改动原来的程序，办法更简单，在前面

SQLCA。LOCK的基础上，加句SQLCA。AUTOCOMMIT=TRUE，这样每数据修改自动提交，就可以避免大多数由于更新产生的死锁和阻塞。

3、最后要对付的是刚才说的被大量应用频繁访问的表（HOT TABLE），如果你的系统允许使用RU加锁级别，那么不用太考虑，因为SELECT已经不会导致锁定了。

但是如果你不能使用RU方式（1里头提到的办法），

那么要采用这样的手段：

使用索引把更新锁，SELECT锁来分开，同时也避免SQLSERVER傻傻为了性能的原因把行锁升级为表锁。

具体办法是建立一个索引，如果可以的话使用聚集索引，因为聚集索引采用的是类似HASH的检索方式，这样当查找索引的时候，就不需要访问数据表了。

另一种办法，是将你SELECT语句中要检索的数据都加到索引中，例如你检索NAME，SEX，AGE，如果你把三个数据都加入了索引，这就意味着SELECT语句只要找到索引，就已经找到了最后要选取的数据（从索引中），这样自然不会去LOCK表了。这样做的时候要针对你的程序仔细选择索引，否则把索引变成了表的一个备份就没有意义了。

这个要看你的应用的情况了,如果一次提交一个完整的事务到数据库处理,那么事务代码在都到达服务器后再执行，和网速关系不大，如果是程序业务逻辑分段处理数据库 *** 作的事务，则有可能因网速的问题提高死锁发生的可能，但也要看你的业务逻辑的情况

以上就是关于用PB开发的一个数据库服务器多个异地客户端使用查询更新速度慢问题解决的技术方法全部的内容，包括:用PB开发的一个数据库服务器多个异地客户端使用查询更新速度慢问题解决的技术方法、远距离和网速慢会影响SQL死锁吗、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！