数据库本地的sa有个叉号_多个客户端(>50)同时使用sa账号操作服务器数据库(sqlserver)会有问题吗？...

写点个人愚见，可能在名词上有错误，但是不会有歧义，也算是抛砖引玉了。

我们先暂定为50个客户端。

因为数据库是基于事务的，所以即便50个客户端同时操作一个表，数据库也会根据事务的先后顺序进行执行，所以在数据库层面，不会出什么问题(但效率惨不忍睹)。

在客户端层面，涉及业务比较多的就是：insert，update，delete和select，这里用i，u，d，s来简化代替。

问题可能出现的点：

1。客户端的逻辑判断：

要避免出现：a客户端d了一条数据，b客户端还要u这条数据；或者，表里面有我们自定义编码的字段，那么多客户端同时插入同类型数据的时候，自定义编码应该如何计算，如何避免冲突；诸如此类的逻辑判断上要捋顺。

2。客户端效率：

我们每做一次i，u，d，s操作，其实就是一次I/O操作，服务器是有I/O上限的，如果频繁的i，u，d操作，客户端势必会感觉到卡顿，所以客户端要在i，u，d的频次方面与数据显示的准确度方面做一个平衡；s的操作相对来说更要命，首先，查询语句中如果运算多，查询的记录数多，势必会占用更多的I/O，此时，客户端势必会变得卡顿，这里建议做一些数据库冗余，比如我们将一些流水的东西，汇总后写到另外一个表里面，这样查询的时候，我们就查询汇总表，这样I/O占用就少了。做冗余操作的时候，我们可以在i，u，d的同时写汇总，也可以在客户端上单独做个“数据处理”的按钮，在空闲时间手动进行处理。

3。服务器配置：

小马拉大车的话，查询类的操作一定要优化好，宗旨就是，查询语句中最好不含有计算类的，查询出来的数据条数越少越好。

4。数据库优化：

什么收缩日志啦，收缩数据库(慎用)啦，在某些情况下会有意想不到的好处。

暂时想到的就这么多，通篇没有说sa，这里说说，sa被多少个客户端使用，都不会影响数据库，那么可能出现的问题点：sa密码静态存储在客户端内，被hacker逆向出来，导致sa直连数据库，哎呦呦，拿服务器权限，数据库泄露，挂木马，再来个蠕虫....(sqlserver是可以调用cmd的，有了cmd就相当于有了一切)

所以建议是内建账号，将账号限定在这个数据库上，避免sa密码泄露。账号的密码要通过加解密的方式存储，比如aes啊rc4啊都行，如果一定要用sa，也没问题，sa密码加解密，做好了也可以。

哦，对了，这里面我提到了客户端卡顿，这个问题主要是是看编程的写法，如果是单线程的写法，会造成窗口界面的假死，可以在查询的过程中处理事件，保持主线程流畅，如果是多线程，就不需要了，当然，无论是单线程还是多线程，该卡还是一样卡(看软件设计，优化，服务器配置)。