MYSQL可以被多个客户端同时连接么?

当然可以。 每个连接同一时刻只能给一个客户端连接用，当然，如果客户端断开了，一段时间之后，又可以给其他客户端连接用。 这个连接数主要取决于 可预期的 客户端数量，或者程序的访问量。 这个数字后期还可以通过修改 my.cnf 文件进行调整的。

既然你用WCF，为什么还让客户端连接数据库呢？

重新设计一下！

客户端只知道服务器的存在，数据库对客户端应该是透明的；

客户端只是想服务器发出请求，至于该请求的处理是对于数据库还是内存或者其他，客户端不需要知道，只要得到服务器的处理结果就可以。

另外，无论客户端还是服务器，用一个数据库连接是不应该的，遇上多线程就麻烦了：不做同步处理会产生错误，做同步处理效率又不行……

------------

你数据库连接使用不对，如果只用一个连接，别说事务，就是并发的普通处理都可能异常；应该每个请求都创建连接、打开、关闭、释放。

处理的方法很简单：

1、并不是所有的地方都需要使用read commit的加锁级别，你从application中设置一句sqlca.lock="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表了。这样做的时候要针对你的程序仔细选择索引，否则把索引变成了表的一个备份就没有意义了。

---