不用写语句的轻量级orm_从ORM框架，聊一聊数据库的设计

浅谈ORM

我是搞C#的菜鸟(别喷)，但是编程思想都是想通的。何不如听一听我这个C#程序员的编程思考呢？

只接触过EF和SqlSugar,正在做的项目用到的就是国产的SqlSugar，个人感觉写法还可以。现在的开发基本上很少还有写原生sql的了，因为ORM框架不仅能提高开发效率，而且还能支持各种数据库，避免了原生sql在更换数据库时的尴尬。但是说白了ORM框架最终也是将object转换成sql语句，不过感觉他应该不会给你优化sql吧。当遇到一些复杂查询的时候，比如多个表关联、各种子查询混在一起的时候，框架就显得有点乏力，感觉很死板。

在程序方面，就拿C#来说吧，当查询少量数据时，ORM框架肯定是没问题，方便高效。如果操作的数据量过大，那肯定会有一些弊端，相对于ADO来说还是显得比较死板，没有原生sql灵活，能够适应各种复杂多变的场景。在查询时要合理利用内存，该缓存的缓存，不要把所有的数据读到内存再做业务处理，而应该是动态的边读边处理。

总而言之，言而总之，这是我在项目中使用ORM框架时的一点理解。不过现在做的项目一般不可能在去拼写sql了，但是我还是觉得还是应该了解一些sql方面的优化。

一、表设计

1、在设计字段类型时，如果某个字段只包含数字，尽量就设计为数值类型，不要设计成字符类型，否则会影响查询和连接的性能。

2、尽量使用varchar或nvarchar代替char和nchar，因为varchar和nvarchar类型长，存储空间小，可以节省存储空间，而且对于查询来说，在一个存储空间相对较小的字段内搜索效率要高一些。

3、在数据量不是很大，使用触发器或自定义函数时，最好是使用表变量，如果是数据量较大可以使用临时表。因为临时表是利用了硬盘，而表变量是占用了内存，因此小数据量当然是内存中的表变量更快。而且在存储过程中，使用表变量与使用临时表相比，减少了存储过程的重新编译量；如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。

二、索引

1、在查询时，为了避免全表扫描，应该首先应考虑在 where 及 order by 涉及的列上建立索引。

2、不是所有的索引都是有用的，当索引列有大量数据重复时，查询可能不会去利用索引，也就提高不了查询效率。

3、索引并不是越多越好，索引在提高查询效率的同时也降低了插入(insert)和更新(update)的效率，所以在建索引时要慎重考虑，不要放在经常更新的字段上，一张表的索引最好不要超过6个。

三、SQL语句查询

1、在程序中最好是不要使用select * from t；select count() from t，用具体的字段名代替“”，这样可以减少数据负担。如果是多表关联查询，不同的表存在相同名称的字段，也会造成混淆。但如果是在后台数据库做临时查询，特别是对表字段不熟悉的时候，用select * 就比较方便了。

2、用exists和not exists代替in和not in，因为in 是把外表和内表作hash 连接，而exists是对外表作loop循环，每次loop循环再对内表进行查询，而且IN不对NULL进行处理，exists会对NULL值进行处理。

3、查询时，在where字句中使用!=、<>、or、in、not in、like以及对字段进行表达式操作或函数操作时，都是进行全表扫描，虽然有些时候没办法避免，但是能换其他方式的，最好不要做全表扫描。

4、不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

5、后台尽量不要向前台返回大数据量，如果数据量过大，更应该注意sql优化，不要返回一些不需要的列，或者也该考虑考虑需求是否合理了。而且尽量避免大事务操作，提高系统的并发能力。

尾声

大家都是搞后端业务的，虽然业务不尽相同。但对数据库的使用来说，都是CURD(虽然有些绝对，哈哈)。更好的理解数据库，不光对个人技术有帮助，长远来说对业务对发展都有提升~

如果大家觉得这种通用性文章比较容易接受，以后可以多写写这类文章~