The Future of MySQL by Monty Widenius and Jay Pipes.

  • Why this talk
    • MySQL and Sun should become more transparent
    • Easier to discuss and act when you have facts
    • when user know the limitations, they know how to go around
  • Threads
    • one connection/thread doesn’t work well
    • no priority threads
    • no way to ensure we have X threads
  • Symptoms
    • Too many context switches
    • we are not using multi-core efficiently
    • does not scale that well after 4-8 cores
  • Solution
    • –thread-handling=pool-of-threads (6.0)
  • Lots of work
  • Memory as a resource
    • no single memory allocator
    • sort_buffer_size is not flexible
    • memory engine has limitations (no varchar/blob)
  • Metadata
    • no online operations
    • .frm files are used to generate table info
    • no versioning
    • they are not ACID
    • slow information schema / SHOW command
  • Privileges
    • not modular or pluggable
    • hard to extend
    • Get community to add LDAP support and ask MySQL/Sun to add ROLE as high priority
  • Pluggable storage engine
    • storage engines are depending on internal mysql data structures (table, field)
    • can only be used with the exact MySQL server version that is compiled
    • think as loadable engine
  • Items
    • hold temporary values during evaluation
    • are not re-entrant
    • hard to make parallel execution of statement
    • we cant  cache prepared statements and stored procedures
  • Parser
    • state machine too large
    • not pluggable
    • not cacheable
    • still uses Bison
    • bad error messages
  • Modularity
    • very monolithic
    • few defined interfaces
    • server and libraries are not documented
    • multiple execution paths
    • no rewrite state for optimizer
  • Stored procedures/triggers
    • not cacheable across connections
    • only supports SQL
    • pre-locking for all tables
    • all cursors are materialized
    • trigger code is not shared across opened tables
    • uses more memory
    • hard to debug and profile
  • Replication
    • not fail safe
    • no synchronous option
    • no consistency checking
    • setup and resync is complicated
    • single thread on the slave
    • no multi master
    • only InnoDB synchronizes with the replication binary log
  • Client/Server protocol
    • only one running query/connection
    • not all statements can be prepared
    • not all language support prepared statement protocol
    • multi-statements/sps with multiple results (need to add the support)
  • Table names
    • stored as files (.frm)
    • file system can be a case sensitive or not
    • falcon has its own interpretation of how things should be done
  • Why Falcon and Maria
    • we don’t have any transactional engine
    • if one fails, another will succeed
  • Phone home
    • no clue for mysql/sun what features mysql users are using
    • endless internals discussion
    • what can be deprecated
    • default values for future
  • Open source project ?
    • very hard to contribute code or ideas
    • customers are using their production systems as bug-finders
    • road map and decision making is not transparent
  • Release policy
    • constantly shipping releases
    • 5.1 was declared RC way too early
    • features are removed/added in RC code (hmm?, what’s wrong)
  • Good news
    • we know the problems and have a good clue of how to fix (most) of them
    • sun is more open source / free software friendly than MySQL
    • sun really understands developer


Related posts:

  1. Notes from Online MySQL Backup in 6.0
  2. Notes from MySQL Cluster
  3. Confused MySQL Server
  4. SQL Server Data Services – Software Design Review