Improving MySQL Server Database Performance

Document Sample
Improving MySQL Server Database Performance Powered By Docstoc
					Even though this article will genuinely improve the memory employed by MySQL the
performance gain might be dramatic depending on your queries and database usage.
MySQL can be a rock solid, lighting quickly database server which has been designed
for two factors pace and efficiency. It could be the Ferrari of databases: Light weight,
quickly and Built for the higher pace tracks! I nonetheless hear an awful lot of stories
from owners whose databases are running two slow. In my experience, the three
principal places to seem for issues are: 1. Faulty Database Design 2. Lousy Queries 3.
Server factors
  Faulty Database Design Correct database design might be the single most essential
factor for the ensuring efficiency and maintainability with the database. Right here is
what you have to answer when designing a desk: Can I decrease the size of
knowledge that every row will have? Right here is what you are able to do: 1. Use
unsigned numeric values when the application is not going to save negative numbers.
Like the quantity ordered of an item in an ecommerce application is never going to
become -$125.
  2. Use Variable length values as an alternative to fixed length worth i.e. utilised
varchar in place of char.
  3. Tend not to use unnecessarily big field sizes. For most ecommerce application
unsigned smallint is extra than sufficient to retailer inventory count. A field described
as unsigned smallint can keep a max benefit of 65535.
  4. Dont ignore normalization; its helps prevent unnecessary repetition of info. The
part B of that is, dont overuse normalization. If the desk is not going to grow in size
substantially, there's no point in normalization. For instance, if the user desk has just
20 rows (i.e. 20 employees in a organization), all attempts of normalization are
  5. Use Keys. Dont decide keys by The customer id has to become indexed from the
order desk. If the order desk is becoming searched 90% of your times by order date, it
makes much more sense to index order date.
  Remember, how a desk will probably be employed must determine how it truly is
designed. Spending time right here will save years of frustration.
  Lousy Queries It sounds too excellent to become true but you wont believe the
number of developers out there who totally suck at writing queries. You will discover
two kinds of undesirable queries: a) Unnecessary Queries: These are the queries that
shouldnt have been made inside initial place. The only method to avoid it can be
asking, Do I actually need to have this info? b) Inefficient Queries: These are the
queries that usually do not use the underlying desk structure or MySQL functions
inside correct way.
  Right here is actually a starting point to begin looking at issue areas: 1. Unnecessary
utilization of Select * statements when the entire processing is becoming carried out
on a single column. The far more info is fetched from the server the extra work
MySQL has to do and much more bandwidth it takes.
  2. Employing sub-query as an alternative to a join. On a correctly designed database,
joins are incredibly rapidly. Making use of sub-queries just shows a lack of
 3. Improper use of Keys. It can be specially valid for range checks. Remember to use
the Explain statement to check the utilization of keys and then use the use crucial
statement in your where clauses to force critical utilization.
 Server Factors Every thing carried out correctly, there nonetheless may well be some
server factors that may possibly be causing the technique to become slow. These are:
1. Hardware associated
 2. Server configuration associated
 Right here is what you are able to do about the hardware: 1. The extra RAM is on
the method the much better it can be. MySQL often fetches info from the RAM and a
lot more the RAM is on the technique, the much better it can be.
 2. Purchase the fastest achievable RAM! A slower RAM is just irony.
 3. As soon as you will be settled with the RAM size and velocity, seem for
processing velocity. MySQL can use multiple processors.
 As soon as you might be satisfied with the hardware, you will find a set of variables
in my.cnf that you should seem at: a) key_buffer_size: This describes the memory
accessible to save the index keys. The default is 8 MB but you may set it to 25% with
the RAM. b) query_cache_size: This worth is by default ..! if you might have a great
deal of repeating queries like in reporting applications and so on, make certain you set
this benefit large. c) table_open_cache: This determines the number of desk
descriptors that MySQL will maintain inside cache. The default worth is 64. But, if
you've 100 users accessing a desk concurrently then this worth require to atleast be
100. You also need to take into considerations joins and so on. Thus, this worth will
need to also be kept large. Read more Software Guide and Review