Skip to main content
select *
Source Link
jkavalik
  • 5.1k
  • 1
  • 13
  • 20

From the EXPLAIN and table structure it can be seen that you are missing some indexes so some queries need to check million rows to return ~20.

SELECT * FROM ooo_video_serie WHERE id_episode='96652' AND active=1 ORDER BY langue,lorde ASC;

this would benefit from index on (id_episode, active) or even (id_episode, active, langue, lorde) but if expected number of rows to return is around 20 then the latter index might be unnecessary.

ALTER TABLE ooo_video_serie ADD INDEX episode_active(id_episode, active);

It might take some time to execute, maybe even half an hour, so plan accordingly and try on test first.

After fixing this one, others might crop up which were overshadowed until now. Analyze the slow log periodically (pt-query-digest is a good help) and fix the worst queries. Often just adding the right index is enough but sometime some rewrite or at least slight modification of the query might be needed.

Other notes:

  • max_connections = 512 - too much, if you get so many clients with slower queries, the server is overloaded and slows to crawl for everyone
  • query_cache_size=128M - too big imho, slow to invalidate; set it to 32MB or even better disable it and just optimize your queries
  • key_buffer_size = 128M - depending on whats the DB size and your available RAM, you might want to make that a bit bigger to better uzilize the indexes - say 10-20% of your available RAM?
  • what about using InnoDB instead of MyISAM?
  • SELECT * is evil, try to list only the columns you really need

From the EXPLAIN and table structure it can be seen that you are missing some indexes so some queries need to check million rows to return ~20.

SELECT * FROM ooo_video_serie WHERE id_episode='96652' AND active=1 ORDER BY langue,lorde ASC;

this would benefit from index on (id_episode, active) or even (id_episode, active, langue, lorde) but if expected number of rows to return is around 20 then the latter index might be unnecessary.

ALTER TABLE ooo_video_serie ADD INDEX episode_active(id_episode, active);

It might take some time to execute, maybe even half an hour, so plan accordingly and try on test first.

After fixing this one, others might crop up which were overshadowed until now. Analyze the slow log periodically (pt-query-digest is a good help) and fix the worst queries. Often just adding the right index is enough but sometime some rewrite or at least slight modification of the query might be needed.

Other notes:

  • max_connections = 512 - too much, if you get so many clients with slower queries, the server is overloaded and slows to crawl for everyone
  • query_cache_size=128M - too big imho, slow to invalidate; set it to 32MB or even better disable it and just optimize your queries
  • key_buffer_size = 128M - depending on whats the DB size and your available RAM, you might want to make that a bit bigger to better uzilize the indexes - say 10-20% of your available RAM?
  • what about using InnoDB instead of MyISAM?

From the EXPLAIN and table structure it can be seen that you are missing some indexes so some queries need to check million rows to return ~20.

SELECT * FROM ooo_video_serie WHERE id_episode='96652' AND active=1 ORDER BY langue,lorde ASC;

this would benefit from index on (id_episode, active) or even (id_episode, active, langue, lorde) but if expected number of rows to return is around 20 then the latter index might be unnecessary.

ALTER TABLE ooo_video_serie ADD INDEX episode_active(id_episode, active);

It might take some time to execute, maybe even half an hour, so plan accordingly and try on test first.

After fixing this one, others might crop up which were overshadowed until now. Analyze the slow log periodically (pt-query-digest is a good help) and fix the worst queries. Often just adding the right index is enough but sometime some rewrite or at least slight modification of the query might be needed.

Other notes:

  • max_connections = 512 - too much, if you get so many clients with slower queries, the server is overloaded and slows to crawl for everyone
  • query_cache_size=128M - too big imho, slow to invalidate; set it to 32MB or even better disable it and just optimize your queries
  • key_buffer_size = 128M - depending on whats the DB size and your available RAM, you might want to make that a bit bigger to better uzilize the indexes - say 10-20% of your available RAM?
  • what about using InnoDB instead of MyISAM?
  • SELECT * is evil, try to list only the columns you really need
Source Link
jkavalik
  • 5.1k
  • 1
  • 13
  • 20

From the EXPLAIN and table structure it can be seen that you are missing some indexes so some queries need to check million rows to return ~20.

SELECT * FROM ooo_video_serie WHERE id_episode='96652' AND active=1 ORDER BY langue,lorde ASC;

this would benefit from index on (id_episode, active) or even (id_episode, active, langue, lorde) but if expected number of rows to return is around 20 then the latter index might be unnecessary.

ALTER TABLE ooo_video_serie ADD INDEX episode_active(id_episode, active);

It might take some time to execute, maybe even half an hour, so plan accordingly and try on test first.

After fixing this one, others might crop up which were overshadowed until now. Analyze the slow log periodically (pt-query-digest is a good help) and fix the worst queries. Often just adding the right index is enough but sometime some rewrite or at least slight modification of the query might be needed.

Other notes:

  • max_connections = 512 - too much, if you get so many clients with slower queries, the server is overloaded and slows to crawl for everyone
  • query_cache_size=128M - too big imho, slow to invalidate; set it to 32MB or even better disable it and just optimize your queries
  • key_buffer_size = 128M - depending on whats the DB size and your available RAM, you might want to make that a bit bigger to better uzilize the indexes - say 10-20% of your available RAM?
  • what about using InnoDB instead of MyISAM?