wdi_10_rails_query_optimization

时间:2021-06-25 20:40:59
【文件属性】:
文件名称:wdi_10_rails_query_optimization
文件大小:57KB
文件格式:ZIP
更新时间:2021-06-25 20:40:59
Ruby ActiveRecord 查询优化 嘘,别告诉任何人……但是你在过去 9 周中构建的所有 Rails 应用程序的数据库性能可能都非常糟糕! 为什么? 因为 Rails 使编写导致N+1 查询的代码变得非常容易。 N+1 是一个性能问题,在页面上显示 N 条记录的过程中,您最终会向数据库发送 N+1(或更多)SQL 查询。 这是非常低效的,因为从 Ruby 到 Postgres 的每次往返都需要时间。 预加载或缓存您知道需要的数据会好得多,因此无论显示多少记录,数据库往返次数都是一个很小的常数。 一个典型的例子可能是显示一个文章列表,每个文章都属于一个用户,并且想要显示关于每个文章用户的信息。 我们使用Article.all对控制器中的文章进行初始查询,然后每次我们在视图中的单个文章上调用.user时,都会发送另一个 SQL 查询来检索该文章的用户。 如果我们有 20 篇文章,我们将进行
【文件预览】:
wdi_10_rails_query_optimization-master
----.gitignore(466B)
----README.md(2KB)
----bin()
--------rails(146B)
--------bundle(129B)
--------spring(510B)
--------rake(90B)
----public()
--------500.html(1KB)
--------robots.txt(202B)
--------422.html(2KB)
--------404.html(2KB)
--------favicon.ico(0B)
----Gemfile(752B)
----db()
--------seeds.rb(495B)
--------migrate()
--------schema.rb(3KB)
----log()
--------.keep(0B)
----app()
--------views()
--------mailers()
--------models()
--------helpers()
--------assets()
--------controllers()
----.rspec(30B)
----vendor()
--------assets()
----Gemfile.lock(5KB)
----config()
--------database.yml(3KB)
--------environment.rb(150B)
--------environments()
--------application.rb(995B)
--------secrets.yml(964B)
--------locales()
--------boot.rb(170B)
--------initializers()
--------routes.rb(793B)
----spec()
--------support()
--------factories()
--------features()
--------rails_helper.rb(2KB)
--------spec_helper.rb(3KB)
----.travis.yml(322B)
----config.ru(154B)
----lib()
--------tasks()
--------assets()
----Rakefile(249B)

网友评论