Optimize MySQL For Developers-Qcon2011
-
Upload
yiwei-ma -
Category
Technology
-
view
643 -
download
2
description
Transcript of Optimize MySQL For Developers-Qcon2011
Optimize MySQL For Developers
QCon Beijing 2011
YangHaichao
Senior MySQL DBA@SINA
http://weibo.com/jackbillow
Agenda
• Architecture of Database-related
• Scaling your Database
• Schema Design
• Optimize Access
Performance vs Architecture
Datastore
• Relational Databases• MySQL
• Non Relational Databases• Memcached
• Redis
• MongoDB
• RD and NRD is Friends or Foes?
• MySQL + Memcached
• MySQL + Redis
Caching
• Put a cache in front of your database• Distribute
• Write-through for scaling reads
• Write-back for scaling reads and writes
• Cache tier
Principles
• Nothing’s perfect but some solutions are
good enough for a while
• Scalability involve partitioning, indexing and
replication
• All data for real-time queries MUST be in
memory. Disk is for writes only
Scaling your database
Replication
• Master - Slave• Only scaling reads
• Master - Master• Scaling reads and writes but many limits
Functional Segmentation
Segment databases into functional areas
• User
• Feed
• Comment
• Attention
• Fans
• …
Horizontal Split
• Hash
• Range
• Lookup table
• Middle layer
Minimize Database
• No business logic
• No distributed transactions
• No joins and sorting
Schema Design
CAP & BASE
Consistency:ACID
Transactions
Availability
(Total
Redundancy)
Partition
Tolerance:
Infinite scaleout
Oracle
RAC
NO
GO
NoSQL
DB
The Schema
• Best stage for optimize performance
• Improve performance is bigest
• Divide and conquer
• Normalize & de-normalize
Data type
• Small is usually better
• Use INT UNSIGNED for IPv4 addresses
• Use TEXT or BLOB sparingly• Consider separate tables
Index
• Over indexing can be an overhead
• On multiple column indexes the order fields
within the index definition is important
• Poor indexes are same as not having any
indexes
• Good selectivity on index fields
Storage Engine
• Understanding benefits and drawbacks of
each storage engine
• Different storage engine has different index
capability
Optimization Access
Thinking in Access
• Any interaction with the database are the
high cost
• Decrease data access is better than SQL
tuning
SQL is not C or C++
Reduce Access to data
• Must specity column in select
• Only use index in query
• Assumsing success
Reduce the Number of Interactions
• Pushing control structures into SQL
• Combining statements
• Fetching all you need at once
Reduce the Number of Interactions
• INSERT ... ON DUPLICATE KEY UPDATE
• REPLACE
• INSERT IGNORE
Reduce CPU computing
• Extensive use of prepared statements and
bind variables
• Column not calculate as far as possible
• Move cpu-intensive work to application
Parallelism
• Reorganizing processing
• Isolating hot spots
• Shortening critical sections
• Dealing with multiple queues
Last, but not least…
• Architecture and design is in the best stages
of improving performance
• Develop huge application you mush keep
scaling data in mind at first
• Perform SQL in very few data accesses is
increasingly important
• Performance tuning is an trade-off and
iterative process
Thank you for coming
Q & A
@jackbillow