Your SlideShare is downloading. ×
0
<ul>Care and Feeding of a MySQL Database for Linux Administrators </ul><ul>Dave Stokes MySQL Community Manager [email_addr...
Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information p...
Simple Introduction This is a general introduction to running a MySQL database server(s) for Linux Administrator
Simple Introduction This is a general introduction to running a MySQL database server(s) for Linux Administrator Database ...
Simple Introduction This is a general introduction to running a MySQL database server(s) for Linux Administrator Database ...
Simple Introduction This is a general introduction to running a MySQL database server(s) for Linux Administrator Database ...
Simple Introduction This is a general introduction to running a MySQL database server(s) for Linux Administrator Database ...
Session Overview <ul><li>Basics of a database server
Hardware
MySQL Configuration
Monitoring Operations
Backups
Replication
Indexes
Tuning
Q/A </li></ul>
How does a Database server work Client SELECT phone  FROM friends WHERE name = ‘Joe’; Server
How does a Database server work Client SELECT phone  FROM friends WHERE name = ‘Joe’; Server PARSE find Joe in friends tab...
How does a Database server work Client SELECT phone  FROM friends WHERE name = ‘Joe’; . . .  Process phone data Server PAR...
How does a Database server work Client SELECT phone  FROM friends WHERE name = ‘Joe’; . . .  Process phone data Server PAR...
Rule #1 <ul><li>Databases love data in memory </li></ul>
Rule #1 <ul><li>Databases love data in memory </li></ul>Corollary #1 – getting data in/out of memory will cause you nightm...
What if it is not in memory? MySQL Please give me the data from the city table OS
What if it is not in memory? MySQL Please give me the data from the city table OS Get inode
What if it is not in memory? MySQL Please give me the data from the city table OS Get inode Ask disk for data
What if it is not in memory? MySQL Please give me the data from the city table OS Get inode Ask disk for data Get data int...
What if it is not in memory? MySQL Please give me the data from the city table Load data into memory OS Get inode Ask disk...
What if it is not in memory? MySQL Please give me the data from the city table Load data into memory OS Get inode Ask disk...
Rule #2 Databases have to do unpredictable queries, random I/O, and sequential scans so slow I/O kills performance
Buffers What happens when you read a file into memory DISK Disk Controller Page Cache User Buffer
Buffers Memory Lookup – 100 nanoseconds, 12GB/sec DISK Disk Controller Page Cache User Buffer
Buffers Memory Lookup – 100 nanoseconds, 12GB/sec DISK seek – 10 milliseconds, 760MB/sec  DISK Disk Controller Page Cache ...
Disk Reads <ul><li>A disk read is 100,000 slower than reading memory </li></ul><ul><ul><li>For comparison  </li><ul><li>10...
100,000 feet is about 19 miles
100,000 kilometers is 15.7 times around Earth's equator </li></ul></ul></ul>
Cache <ul><li>Write back  and write through  caches </li></ul>Writethrough on disk Writethrough on controller Disk Control...
Cache <ul><li>Recommended setup </li></ul>Writethrough on disk Writeback on controller Disk Controller DISK
SSD <ul><li>Use standard RAID controller </li></ul><ul><ul><li>SSD as writeback cache
Battery backed
$2.5/GB verses .075/GB
Very fast seek time
Density </li></ul></ul>
Hardware recommendations <ul><li>Memory – lots of it, ecc </li></ul>
Hardware recommendations <ul><li>Memory – lots of it, ecc
DISKs – more spindles, high speed, fast controllers, RAID 10, write back cache, and XFS/ZFS/ext4 not ext2/3 </li></ul>
Hardware recommendations <ul><li>Memory – lots of it, ecc
DISKs – more spindles, high speed, fast controllers, RAID 10, write back cache, and XFS/ZFS/ext4 not ext2/3
Write-through caches with battery backup units for disks must be monitored, and have life span much longer than planned ou...
Hardware recommendations <ul><li>Memory – lots of it, ecc
DISKs – more spindles, high speed, fast controllers, RAID 10, write back cache, and XFS/ZFS/ext4 not ext2/3
Write-through caches with battery backup units for disks must be monitored, and have life span much longer than planned ou...
CPUs, Core less important (spend money  on Memory and IO) </li></ul>
Quick Security Warning! <ul><li>MySQL login security is primitive. </li></ul><ul><ul><li>Database  mysql  has  users  table
'jsmith'@'co.com' or 'fred'@'10.10.%' </li><ul><li>Matches  host , then  user , then  password  fields </li><ul><li>Be exp...
Can get Byzantine quickly
Use a GUI </li></ul></ul>
When  root  is the  root  of your  root  problem OR stingy is your best friend <ul><li>Linux server has root </li></ul><ul...
Dangerous </li></ul></ul><ul><li>MySQL daemon has root </li></ul><ul><ul><li>Highly privileged
Dangerous
Understand MySQL priv system and be stingy
Proxy and plug-in adapters soon
Really limit access, not just play at it </li></ul></ul>Linux root is not the same as MySQL root but  both can be dangerou...
Installation <ul><li>Use pre built MySQL packages </li></ul>
Installation <ul><li>Use prebuilt MySQL packages
Don’t double up with other services </li></ul>
Installation <ul><li>Use prebuilt MySQL packages
Don’t double up with other services
Supplied configuration files are  OLD ! </li></ul>
Installation <ul><li>Use prebuilt MySQL packages
Don’t double up with other services
Supplied configuration files are  OLD !
Move logs to different disk than data </li></ul>
Installation <ul><li>Use prebuilt packages
Don’t double up with other services
Supplied configuration files are  OLD !
Move logs to different disk than data
Spread data over different drives </li></ul>
Installation <ul><li>Use prebuilt packages
Don’t double up with other services
Upcoming SlideShare
Loading in...5
×

The care and feeding of a MySQL database

1,051

Published on

Presentation of Care and Feeding of a MySQL Database. Rev Oct 2011

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,051
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
66
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Thanks for coming Intro What is new in MySQL 5.5
  • A single 40 minute session can not turn you into a good DBA than the same time to turn a novice into a good system admin. We have been promoting MySQL on generic hardware – but sometimes you need better performance and that may require specialized hardware.
  • Most Linux based services are CPU bound – not database servers
  • Databases are the heart of the LAMP stack. Poor hardware choice is like an unhealthy heart.
  • This session will cover much of what you need to know for a solid foundation to make your MySQL database per optimally but …
  • That last 20% is where a good DBA comes in to play Indy Car example
  • Gross over simplification! Client wants phone number for Joe from database
  • Database server parses query, finds record in memory, returns phone number
  • Client program proceeds with phone number
  • This is an optimal situation.
  • Rule 1
  • The database needs to get data not in memory off storage Also updates need to get written to disk Disk is MUCH slower than memory
  • Another vast over simplification
  • OS has to pry open file
  • Then pull out data
  • Load data into memory
  • Hand data back to database
  • Much longer
  • I/O subsystem is critical to performance. Spend money here instead of latest speedy processor.
  • Minimize contention
  • KNOW your BBU system – does it occasionally going into self test mode and could that self test mode happen at the wrong time?
  • Spend money on memory and disks over latest CPU
  • MySQL supports .DEB, RPM, Windows, tar balls, and source code. Pre-built uses better compilers and libraries than you probably have access to.
  • Do not run other services (HTTP, LDAP, memcached, etc) on same box if you need performance.
  • Large system 2-4 GB ram
  • Do not let logs fill disks..
  • Move to another spindle to avoid contention
  • Queries over 1 second, configurable, go into slow query log. But you may need full table scans or complex queries from time to time.
  • May be a quick gain (more later)
  • You need a way to check on how well your database is running, or not. Granularity depends on application.
  • More later
  • Two choices -- mysqldump, MySqL Enterprise backup, LVM snapshots or some variant of these
  • Need to determine before hand what you can lose, what you can not lose, service levels, and develop strategy.
  • Look for single points of failure Watch out for organization flaws – one person knows backup system or one person can call for support
  • Been around for a while
  • Recent development
  • Without index, entire table must be read With index, can go directly to record usually via a B Tree
  • Do not index everything!
  • 200 MPH Ferrari in rush hour traffic Data warehousing usually done without indexes
  • Leave composite indexes for DBAs – but know about them and ask
  • Ext-2 and ext-3 lock a per-inode mutex for the duration of a write. This means that ext-2 and ext-3 do not allow concurrent writes to a file and that can prevent you from getting the write throughput you expect when you stripe a file over several disks with RAID. XFS does not do this which is one of the reasons many people prefer XFS for InnoDB. I don&apos;t know whether ext-4 does this.   Depending on what caches are enabled in your storage, this can have reduce disk write throughput. Even when you have a battery backed write cache, unless the batteries can be hot-swapped, it is likely that at some point in time your server will run in production with the RAID write cache disabled.   
  • Divide the data in logical small chunks, chunks. I.E. Account receivables by month instead of year so that smaller segment can be processed
  • To easy to add tables here, de-normalize there, quick fix there, and soon the data is an unusable mess. Plan what your data looks like and make smart choices as needs grow.   
  • A bad SQL statement can ruin all the work you have done. Use EXPLAIN to check for the efficiency of   statements. Seek to minimize that data needed, no ‘SELECT *’.
  • Transcript of "The care and feeding of a MySQL database"

    1. 1. <ul>Care and Feeding of a MySQL Database for Linux Administrators </ul><ul>Dave Stokes MySQL Community Manager [email_address] </ul>
    2. 2. Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.
    3. 3. Simple Introduction This is a general introduction to running a MySQL database server(s) for Linux Administrator
    4. 4. Simple Introduction This is a general introduction to running a MySQL database server(s) for Linux Administrator Database servers have needs different than SMTP, HTTP, or other servers
    5. 5. Simple Introduction This is a general introduction to running a MySQL database server(s) for Linux Administrator Database servers have needs different than SMTP, HTTP, or other servers Hardware choices are critical! (do not go cheap)
    6. 6. Simple Introduction This is a general introduction to running a MySQL database server(s) for Linux Administrator Database servers have needs different than SMTP, HTTP, or other servers Hardware choices are critical! (do not go cheap) Tuning to 80% efficiency is relatively easy
    7. 7. Simple Introduction This is a general introduction to running a MySQL database server(s) for Linux Administrator Database servers have needs different than SMTP, HTTP, or other servers Hardware choices are critical! (do not go cheap) Tuning to 80% efficiency is relatively easy (last 20% is tricky)
    8. 8. Session Overview <ul><li>Basics of a database server
    9. 9. Hardware
    10. 10. MySQL Configuration
    11. 11. Monitoring Operations
    12. 12. Backups
    13. 13. Replication
    14. 14. Indexes
    15. 15. Tuning
    16. 16. Q/A </li></ul>
    17. 17. How does a Database server work Client SELECT phone FROM friends WHERE name = ‘Joe’; Server
    18. 18. How does a Database server work Client SELECT phone FROM friends WHERE name = ‘Joe’; Server PARSE find Joe in friends table in memory return phone
    19. 19. How does a Database server work Client SELECT phone FROM friends WHERE name = ‘Joe’; . . . Process phone data Server PARSE find Joe in friends table in memory return phone
    20. 20. How does a Database server work Client SELECT phone FROM friends WHERE name = ‘Joe’; . . . Process phone data Server PARSE find Joe in friends table in memory return phone What was that about memory???
    21. 21. Rule #1 <ul><li>Databases love data in memory </li></ul>
    22. 22. Rule #1 <ul><li>Databases love data in memory </li></ul>Corollary #1 – getting data in/out of memory will cause you nightmares!
    23. 23. What if it is not in memory? MySQL Please give me the data from the city table OS
    24. 24. What if it is not in memory? MySQL Please give me the data from the city table OS Get inode
    25. 25. What if it is not in memory? MySQL Please give me the data from the city table OS Get inode Ask disk for data
    26. 26. What if it is not in memory? MySQL Please give me the data from the city table OS Get inode Ask disk for data Get data into buffer
    27. 27. What if it is not in memory? MySQL Please give me the data from the city table Load data into memory OS Get inode Ask disk for data Get data into buffer Hand buffer off
    28. 28. What if it is not in memory? MySQL Please give me the data from the city table Load data into memory OS Get inode Ask disk for data Get data into buffer Hand buffer off Much longer than just reading from memory
    29. 29. Rule #2 Databases have to do unpredictable queries, random I/O, and sequential scans so slow I/O kills performance
    30. 30. Buffers What happens when you read a file into memory DISK Disk Controller Page Cache User Buffer
    31. 31. Buffers Memory Lookup – 100 nanoseconds, 12GB/sec DISK Disk Controller Page Cache User Buffer
    32. 32. Buffers Memory Lookup – 100 nanoseconds, 12GB/sec DISK seek – 10 milliseconds, 760MB/sec DISK Disk Controller Page Cache User Buffer
    33. 33. Disk Reads <ul><li>A disk read is 100,000 slower than reading memory </li></ul><ul><ul><li>For comparison </li><ul><li>100,000 minutes is about 69.5 days
    34. 34. 100,000 feet is about 19 miles
    35. 35. 100,000 kilometers is 15.7 times around Earth's equator </li></ul></ul></ul>
    36. 36. Cache <ul><li>Write back and write through caches </li></ul>Writethrough on disk Writethrough on controller Disk Controller DISK
    37. 37. Cache <ul><li>Recommended setup </li></ul>Writethrough on disk Writeback on controller Disk Controller DISK
    38. 38. SSD <ul><li>Use standard RAID controller </li></ul><ul><ul><li>SSD as writeback cache
    39. 39. Battery backed
    40. 40. $2.5/GB verses .075/GB
    41. 41. Very fast seek time
    42. 42. Density </li></ul></ul>
    43. 43. Hardware recommendations <ul><li>Memory – lots of it, ecc </li></ul>
    44. 44. Hardware recommendations <ul><li>Memory – lots of it, ecc
    45. 45. DISKs – more spindles, high speed, fast controllers, RAID 10, write back cache, and XFS/ZFS/ext4 not ext2/3 </li></ul>
    46. 46. Hardware recommendations <ul><li>Memory – lots of it, ecc
    47. 47. DISKs – more spindles, high speed, fast controllers, RAID 10, write back cache, and XFS/ZFS/ext4 not ext2/3
    48. 48. Write-through caches with battery backup units for disks must be monitored, and have life span much longer than planned outages </li></ul>
    49. 49. Hardware recommendations <ul><li>Memory – lots of it, ecc
    50. 50. DISKs – more spindles, high speed, fast controllers, RAID 10, write back cache, and XFS/ZFS/ext4 not ext2/3
    51. 51. Write-through caches with battery backup units for disks must be monitored, and have life span much longer than planned outages
    52. 52. CPUs, Core less important (spend money on Memory and IO) </li></ul>
    53. 53. Quick Security Warning! <ul><li>MySQL login security is primitive. </li></ul><ul><ul><li>Database mysql has users table
    54. 54. 'jsmith'@'co.com' or 'fred'@'10.10.%' </li><ul><li>Matches host , then user , then password fields </li><ul><li>Be explicit </li></ul></ul><li>Proxy and Pluggable logins on the way </li></ul></ul><ul><li>MySQL privilege security </li></ul><ul><ul><li>GRANT functions or access
    55. 55. Can get Byzantine quickly
    56. 56. Use a GUI </li></ul></ul>
    57. 57. When root is the root of your root problem OR stingy is your best friend <ul><li>Linux server has root </li></ul><ul><ul><li>Highly privileged
    58. 58. Dangerous </li></ul></ul><ul><li>MySQL daemon has root </li></ul><ul><ul><li>Highly privileged
    59. 59. Dangerous
    60. 60. Understand MySQL priv system and be stingy
    61. 61. Proxy and plug-in adapters soon
    62. 62. Really limit access, not just play at it </li></ul></ul>Linux root is not the same as MySQL root but both can be dangerous to you!!!
    63. 63. Installation <ul><li>Use pre built MySQL packages </li></ul>
    64. 64. Installation <ul><li>Use prebuilt MySQL packages
    65. 65. Don’t double up with other services </li></ul>
    66. 66. Installation <ul><li>Use prebuilt MySQL packages
    67. 67. Don’t double up with other services
    68. 68. Supplied configuration files are OLD ! </li></ul>
    69. 69. Installation <ul><li>Use prebuilt MySQL packages
    70. 70. Don’t double up with other services
    71. 71. Supplied configuration files are OLD !
    72. 72. Move logs to different disk than data </li></ul>
    73. 73. Installation <ul><li>Use prebuilt packages
    74. 74. Don’t double up with other services
    75. 75. Supplied configuration files are OLD !
    76. 76. Move logs to different disk than data
    77. 77. Spread data over different drives </li></ul>
    78. 78. Installation <ul><li>Use prebuilt packages
    79. 79. Don’t double up with other services
    80. 80. Supplied configuration files are OLD !
    81. 81. Move logs to different disk than data
    82. 82. Spread data over different drives
    83. 83. Backups are necessary – and practice recovery! </li></ul>
    84. 84. Monitoring Operations <ul><li>Slow query log -- not all long running queries are bad </li></ul>
    85. 85. Monitoring Operations <ul><li>Slow query log -- not all long running queries are bad
    86. 86. Log queries not using indexes </li></ul>
    87. 87. Monitoring Operations <ul><li>Slow query log -- not all long running queries are bad
    88. 88. Log queries not using indexes
    89. 89. Use monitoring software – MEM, Innotop, Cacti, Munin, Nagios, etc – and pay attention to it </li></ul>
    90. 90. Monitor!!!
    91. 91. Monitoring Operations <ul><li>Slow query log -- not all long running queries are bad
    92. 92. Log queries not using indexes
    93. 93. Use monitoring software – MEM, Innotop, Cacti, Munin, Nagios, etc – and pay attention to it
    94. 94. More in tuning …. </li></ul>
    95. 95. Backups Backups are usually some sort of disk snap shot or serializing data to a file
    96. 96. Backups Backups are usually some sort of disk snap shot or serializing data to a file The more the better but you need to know steps to recover dropped table, lost databases, or mangled data
    97. 97. Backups Backups are usually some sort of disk snap shot or serializing data to a file The more the better but you need to know steps to recover dropped table, lost databases, or mangled data. Use data replication to a slave and then backup slave
    98. 98. Backups Backups are usually some sort of disk snap shot or serializing data to a file The more the better but you need to know steps to recover dropped table, lost databases, or mangled data. Use data replication to a slave and then backup slave Be paranoid!!!!!
    99. 99. Replication Replication for MySQL is the binary log for the master being copied to a slave. The slave then updates its copy of the data
    100. 100. Replication Replication for MySQL is the binary log for the master being copied to a slave. The slave then updates its copy of the data Two types: <ul><li>Asynchronous – server does not check changes sent to slave before proceeding </li></ul>
    101. 101. Replication Replication for MySQL is the binary log for the master being copied to a slave. The slave then updates its copy of the data Two types: <ul><li>Asynchronous – server does not check changes sent to slave before proceeding
    102. 102. Semi Synchronous – server checks that slave received changes before proceeding </li></ul>
    103. 103. Replication -- threads Currently single threaded – 5.6 will fix that
    104. 104. Replication -- network Network latency will affect MySQL replication. So plan network topology to minimize bandwidth competition with other systems/services.
    105. 105. Replication -- network Network latency will affect MySQL replication. So plan network topology to minimize bandwidth competition with other systems/services. Slaves do not need to be as fast as the master but try to keep things reasonably close
    106. 106. Replication -- network Network latency will affect MySQL replication. So plan network topology to minimize bandwidth competition with other systems/services. Slaves do not need to be as fast as the master but try to keep things reasonably close Do not have to replicate all tables/databases to all slaves. Cut down on traffic by replicating what is needed!
    107. 107. <ul><li>Write to one master
    108. 108. Read from many slaves, easily add more as needed
    109. 109. Perfect for read/write intensive apps </li></ul><ul>Application </ul><ul>MySQL Replication </ul><ul>Load Balancer </ul><ul>MySQL Database </ul><ul>Replication Enables Scalability </ul><ul>Writes & Reads </ul><ul>Reads </ul><ul>Reads </ul>
    110. 110. Indexes are good Without Index DB needs to scan entire table or table scan With Index DB can go right to record
    111. 111. Indexes, the bad <ul><li>Overhead -- space, speed, maintenance </li></ul>
    112. 112. Indexes, the bad <ul><li>Overhead -- space, speed, maintenance
    113. 113. Not a panacea – does not cure all problems </li></ul>
    114. 114. Indexes, the bad <ul><li>Overhead -- space, speed, maintenance
    115. 115. Not a panacea – does not cure all problems
    116. 116. Will not help if you need to perform a table scan </li></ul>
    117. 117. Indexes, the bad <ul><li>Overhead -- space, speed, maintenance
    118. 118. Not a panacea – does not cure all problems
    119. 119. Will not help if you need to perform a table scan
    120. 120. Composite indexes can be tricky – YearMonthDay usually better than DayMonthYear </li></ul>
    121. 121. Tuning to 80% <ul><li>Use InnoDB </li></ul>
    122. 122. Tuning to 80% <ul><li>Use InnoDB
    123. 123. Set innodb_buffer_pool_size to 70-80% of memory </li></ul>
    124. 124. Tuning to 80% <ul><li>Use InnoDB
    125. 125. Set innodb_buffer_pool_size to 70-80% of memory
    126. 126. Use XFS/ZFS/ext4 </li></ul>
    127. 127. Tuning to 80% <ul><li>Use InnoDB
    128. 128. Set innodb_buffer_pool_size to 70-80% of memory
    129. 129. Use XFS/ZFS/ext4
    130. 130. Partition data -- divide and conquer </li></ul>
    131. 131. Tuning to 80% <ul><li>Use InnoDB
    132. 132. Set innodb_buffer_pool_size to 70-80% of memory
    133. 133. Use XFS/ZFS/ext4
    134. 134. Partition data -- divide and conquer
    135. 135. Architect your data </li></ul>
    136. 136. Tuning to 80% <ul><li>Use InnoDB
    137. 137. Set innodb_buffer_pool_size to 70-80% of memory
    138. 138. Use XFS/ZFS/ext4
    139. 139. Partition data -- divide and conquer
    140. 140. Architect your data
    141. 141. Review your SQL statements </li></ul>
    142. 142. Don't hurt yourself <ul><li>Some RAID controllers have a battery learning cycle when BBU goes write-back. Schedule during off-time!
    143. 143. Minimize time for most frequent queries
    144. 144. Keep on top of upgrades
    145. 145. - 5.5 20% faster than 5.1 </li></ul>
    146. 146. Tuning Past 80% <ul><li>Will depend on your data </li></ul>
    147. 147. Tuning Past 80% <ul><li>Will depend on your data
    148. 148. Lots of Tuning Help Available </li></ul>
    149. 149. Tuning Past 80% <ul><li>Will depend on your data
    150. 150. Lots of Tuning Help Available </li></ul><ul><ul><li>High Performance MySQL – Schwartz et al
    151. 151. MySQL Administrator's Bible – Cabral </li></ul></ul>
    152. 152. Tuning Past 80% <ul><li>Will depend on your data
    153. 153. Lots of Tuning Help Available </li></ul><ul><ul><li>High Performance MySQL – Schwartz et al
    154. 154. MySQL Administrator's Bible – Cabral
    155. 155. OurSQL podcast </li></ul></ul>
    156. 156. Tuning Past 80% <ul><li>Will depend on your data
    157. 157. Lots of Tuning Help Available </li></ul><ul><ul><li>High Performance MySQL – Schwartz et al
    158. 158. MySQL Administrator's Bible – Cabral
    159. 159. OurSQL podcast
    160. 160. Performance forum on Forums.MySQL.Com
    161. 161. Planet.MySQL.com & MySQL.Com </li></ul></ul>
    162. 162. Tuning Past 80% <ul><li>Will depend on your data
    163. 163. Lots of Tuning Help Available </li></ul><ul><ul><li>High Performance MySQL – Schwartz et al
    164. 164. MySQL Administrator's Bible – Cabral
    165. 165. OurSQL podcast
    166. 166. Performance forum on Forums.MySQL.Org
    167. 167. Planet.MySQL.com & MySQL.com </li></ul></ul><ul><li>Skilled DBA </li></ul>
    168. 168. Tuning Past 80% <ul><li>Will depend on your data
    169. 169. Lots of Tuning Help Available </li></ul><ul><ul><li>High Performance MySQL – Schwartz et al
    170. 170. MySQL Administrator's Bible – Cabral
    171. 171. OurSQL podcast
    172. 172. Performance forum on Forums.MySQL.Org
    173. 173. Planet.MySQL.COM & MySQL.Com </li></ul></ul><ul><li>Skilled DBA </li></ul><ul><ul><li>Defined as obsessive professional looking to save nanoseconds off queries, possess current backups, helps developers rewrite queries, plans for future, and watches buffer hits rates compulsively. </li></ul></ul>
    174. 174. Big hint <ul><li>Seek to optimize the system as a whole. Often the database is blamed for systemic slowness when other components are at fault. </li></ul>
    175. 175. General Last hints <ul><li>SQL </li></ul><ul><ul><li>Fetch needed data only, no SELECT *
    176. 176. Use EXPLAIN
    177. 177. Think in data sets, not nested loops
    178. 178. Set benchmark times
    179. 179. Use smallest data type possible
    180. 180. Rewrite subqueries to joins </li></ul></ul><ul><li>Mysqld </li></ul><ul><ul><li>Pay attention to new technologies, updates
    181. 181. Know which buffers are per-session, global
    182. 182. Do not ignore log files </li></ul></ul>
    183. 183. Q&A [email_address] - http://NorthTexasMySQL.org
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×