public
Description: Query Analyzer Plugin for ActiveRecord/MySQL on Merb
Homepage:
Clone URL: git://github.com/bchiu/merb_query_analyzer.git
commit  2fcf6f7a6472756c9fb5b9e9fbadfe78fc572a82
tree    7e452ebf521daaab23f28869d20082a5bb903a9e
parent  bb495a8fa47305a1258d917ffc563f632d52cd85
README
= merb_query_analyzer

  Query Analyzer Plugin for ActiveRecord/MySQL on Merb

  The Merb Query Analyzer plugin will expand the usability of your log files
  by providing query analysis using the MySQL query execution plan. Each SQL
  select query will be 'EXPLAIN'ed and added to the log files right below
  the original query.
  
  Using this plugin and a good understanding of the results, you will be 
  able to analyze and optimize the queries your application is making.
  
  Refer to http://www.mysql.org/doc/refman/5.0/en/explain.html for more
  information on understanding the results. 

== Installation

  git clone git://github.com/bchiu/merb_query_analyzer.git
  cd merb_query_analyzer
  rake install
  add: dependency 'merb_query_analyzer' to development.rb

== Configuration

  # color options:
  # :black
  # :red
  # :green
  # :yellow
  # :blue
  # :magenta
  # :cyan
  # :white
  #
  Merb::Plugins.config[:merb_query_analyzer] = {
    :foreground => :magenta,
    :background => :black
  }

== Example Use

  Here is a real life usage of the plugin that detected the omission of indexes 
  on a table. In this case, it was a join table and the keys didn't have 
  indexes (silly me!). Names have been changed to protect the innocent (and 
  make it fit 80 columns).

  # development.log
  
  P Load (0.008669)
   => SELECT p.* FROM p INNER JOIN d ON p.id = d.p_id WHERE (d.p_id = 2 AND ((d.type = 'P'))) 
  
  Analyzing P Load
     
  select_type | key_len | type   | Extra       | id | possible_keys | rows | table  | ref    | key    
  ----------------------------------------------------------------------------------------------------
  SIMPLE      |         | ALL    | Using where | 1  |               | 74   |    d   |        |        
  SIMPLE      | 4       | eq_ref | Using where | 1  | PRIMARY       | 1    |    p   | d.p_id | PRIMARY

== Analyze the results

  Looking at the results of the execution plan, we can see that the lookup in
  the d table is missing an index (possible_keys=null) and performed a full 
  table scan (type=ALL) to satisfy the WHERE condition. In this case, there was only one 
  row that matched the condition in the table, but MySQL still had to search all 74 rows 
  in the table to find it, a key indicator of a missing
  or malformed index(es). Once it has pulled all the records to satisfy the WHERE, it then
  starts the p table join. This time, it was able to match d.p_id to p.id using
  the PRIMARY key on the p table. The type=eq_ref indicates a 1 to 1 match against a primary 
  or unique column.

  Lets add some indexes to the join table and see if we can cut that full table scan down in the
  number of rows it needs to search.
  
  #> merb-gen migration AddIndexesToD
  
  # file: 005_add_indexes_to_d
  class AddIndexesToD < ActiveRecord::Migration
    def self.up
      add_index :d, [ :p_id, :type ]
      add_index :d, :type
    end
  
    def self.remove
      remove_index :d, [ :p_id, :type ]
      remove_index :d, :type  
    end
  end

  Now that we have an index on the foreign_key column and type, lets re-run the query and
  see if we got rid of that full table scan.
  
  # development.log
  
  P Load (0.009011)   
   => SELECT p.* FROM p INNER JOIN d ON p.id = d.p_id WHERE (d.p_id = 2 AND ((d.type = 'P'))) 
  
  Analyzing P Load
     
  key_len | type   | Extra       | id | possible_keys                  | rows | table | ref    | key                     
          
  ----------------------------------------------------------------------------------------------------------------
  255     | ref    | Using where | 1  | d_p_id_type_index,d_type_index | 1    |   d   | const  | d_p_id_type_index
  4       | eq_ref | Using where | 1  | PRIMARY                        | 1    |   p   | d.p_id | PRIMARY                 
          
  
  Okay. Now MySQL is using an index satisfy the WHERE condition. Using the index, it was able to
  find the single row that matched, preventing the full table scan.

== Credits:

  This plugin is a port of the popular query_analyzer plugin for Rails by Bob Silva:
  http://agilewebdevelopment.com/plugins/owner/62