[wp-trac] [WordPress Trac] #21663: Use PDO for MySQL queries when PDO is available

[WordPress Trac]

#21663: Use PDO for MySQL queries when PDO is available
--------------------------------------------------+------------------
 Reporter:  scottconnerly                         |       Owner:
     Type:  task (blessed)                        |      Status:  new
 Priority:  normal                                |   Milestone:  3.6
Component:  Database                              |     Version:  3.5
 Severity:  normal                                |  Resolution:
 Keywords:  dev-feedback has-patch needs-testing  |
--------------------------------------------------+------------------

Comment (by bpetty):

 In regards to performance, this is the driver we're talking about, not the
 query itself. It's almost never the bottleneck compared with the query,
 your indexes, or your PHP code working on the results (which should
 already be cached anyway if it's been optimized properly).

 Of course this doesn't stop people from benchmarking them anyway.
 [http://jnrbsn.com/2010/06/mysqli-vs-pdo-benchmarks Many] of
 [http://webdevrefinery.com/forums/topic/10380-database-extension-mysql-
 mysqli-pdo-benchmarks/ them] don't find more than a 5% difference in
 performance with equivalent operations. Just as many find wildly different
 results. One benchmark even [http://net.tutsplus.com/tutorials/php/pdo-vs-
 mysqli-which-should-you-use/ claims] (though without publishing test
 details/results) that the original MySQL extension is faster in all tests
 they ran.

 Regardless, don't believe most of the benchmarks out there in regards to
 this. Most of them don't configure their sandbox properly for benchmarking
 (tuning various optimization settings, clearing caches, etc), and don't
 measure the appropriate aspects, often mixing performance measurements of
 tasks unrelated to the driver itself such as tests that spend 90% of the
 time running the SQL query itself, or code that extracts data from the
 results - assuming that these will perform consistently enough that they
 won't affect measurements, and assuming that this is mostly how the driver
 is being used across all installations of the application.

 Of course, we should be profiling these changes anyway, just in case some
 part of it is inefficiently written (outside of use of the driver anyway)
 and does make a significant difference for a default WP installation.
 However, focus on compatibility is much more important than database
 driver performance (and staying on what everyone is already using right
 now until PHP is upgraded isn't hurting anyone's current performance). I
 haven't seen any guides or presentations on WordPress performance ever
 suggest possibly switching this out to speed up WordPress (and it's
 ridiculous how many WP performance presentations I've seen, there's at
 least one per WordCamp). There's significantly more important aspects to
 consider when it comes to performance.

 The scope of this ticket was originally to address the issue of
 compatibility, not performance. If performance was really a concern here,
 we would have seen a patch doing exactly the same thing here well before
 the MySQL extension was deprecated.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/21663#comment:68>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software