算法相同,纯SQL在数据库内运行 与Golang调用database. SQL执行的速率?

如上,请问有大神比较过吗?

已邀请:

eahau

赞同来自:

不是大神!特地注册个账号回答.回答这个问题之前,我还不清楚Golang调用database. SQL是什么意思?是拼sql然后通过网络传输到db服务器吗?如果是这样的话,肯定是前者快.因为前者是sql存储服务器本地,相比后者拼sql然后通过网络传输,减少了网络传输和带宽的成本.拙见

DennisMao

赞同来自:

楼上说得对,在阿里云的RDB优化手册也有说过,直接执行当然会比在客户端调用要快,但是对比起执行花费的时间,这点传输时间并不算什么,特别是遇到业务开发。优先加快业务开发的完成,再去对SQL语句进行优化优化执行速度,最后再考虑传输中间的花费。个人拙见

gopherr

赞同来自:

纯SQL在数据库端执行肯定要比客户端连接上去效率高, 这中间还牵扯一个预编译的问题。 客户端这边一个是连接交互消耗资源和时间, 另外一个就是缓存预编译问题了。 在数据库端缓存的代码执行肯定比客户端快不少,代价就是逻辑实现困难一些。

xiaoma

赞同来自:

另外,用xorm的,做了分表和索引优化。用plpgsql的只用了索引优化

tsingson

赞同来自:

回复下:

  1. 与 c++ 驱动相比, 同类数据库下, golang 的 database.sql 效率不高
  2. 如果 sql 语句是预编译的话( 在数据库上作 prepare 预编译后), sql 执行效率比外部调用要好.
  3. 不考虑并发情况下, 同样逻辑的 sql 存储过程, 效率与预编译后的 sql 一样, 高效不错
  4. 如果可能的情况下, 请不要在 golang 或任何 sql 数据库外部分开发语言中进行 sql 多态化拼装, 比如, select ............from xxxx where xx=???? and kk=???? 与 select .........from xxxx where xx=??? 一个 where 匹配条件与两个where 匹配条件 应该拆分两两条已经 prepare 好的语句, 放在数据库内部, 调用时是用 prepare_sql_1 ( ? ) 与 prepare_sql_2( ?, ? ) 来调用
  5. 考虑执行效率情况下, 自动拼装的 ORM 或类 ORM 都在测试对比后, 考虑是否弃用或部分弃用 ORM, ------> 针对慢 sql 语句, 使用自写优化后的 原生 sql 并进行 prepare
  6. 以上, 30%经验来自 mysql / maria db, 70%经验来自 postgresql 10+, 仅供参考

祝愉快.

tsingson

赞同来自:

晕, 回复后再编辑好像不太好用. 补充如下:

  1. 考虑到很多 sql 调用后, 相当多是提供 REST api , 比如

    client <------( REST API / json / jsonb / bson ) --------> lb <-------> go web( with local cache like redis / fastcache / mencache / groupcache ...) <---> SQL DB

    在这样情况下, 建议在数据库内进行 json 序列化( 而不是在 go 中进行序列化) , 同时在 go 中进行本地缓存

    当然了, 这一条建议, 可能很多朋友会有不同看法, 毕竟, 听说某大厂的开发规范禁止在 sql 上作业务相关逻辑而应该在 java 上作业务逻辑. 但我还是说, case by case 分情况吧, 单表或双表联查这一类的 CRUD, 除索引/索引/索引以外, 真的没什么太多优化空间, 但多表 join 情况下, 视图与物化视图 + 视图上的主健索引 + 视图上的适当索引, 效率能提升不少.

最后, 仅仅考虑 sql 执行效率的情况很少, 虽然 db access 是重点考虑的性能优化点, 但不一定是第一优先级去优化的点.

  1. 另, xorm 我用过, 但在 postgresql 上, 个人即不用 github.com/go-pg/pg 也不用 xorm , 而是用 github.com/jackc/pgx 这个库

ok, 欢迎讨论.

要回复问题请先登录注册