Most of them are in, and they’re available on the NYPHPCon web site.

And if you missed it, I also posted some notes from the conference.

These are my notes from a presentation by Ilia Alshanetsky. This post may contain inaccuracies, typos, boo-boos, etc.

PDO stands for “PHP Data Objects Layer”: A data-access abstraction layer.

• Common interface for any number of database systems
• PHP extension
• Designed to simplify features.
• Only available to PHP 5 or 5.1; requires a level of OOPHP that’s only available to PHP 5

Why PDO?

• Consistency of development across databases; code is the same for MySQL, PostgreSQL, Oracle, etc.
• Current APIs don’t take full advantage of new PHP’s features
• Current APIs don’t take full advantage of all of the features available in the database

Installation

• Need to install PDO, made up of the core and the drivers.
• Can install using PECL.
• Can install by recompiling PHP

Using PDO

• Create an instance of the object.
• PDO uses a single connection string as the lone parameter.
  • Connection failure handling: Instantiation failure causes an exception error. Use inside of a try…catch block to retrieve and log the error number.
  • Functions available to report errors

Persistent Connections

• Persistent connections help speed up web apps, particularly with Oracle and PostgreSQL databases
• Create persistent connections using a class constant ATTR_PERSISTENT
• Will need to figure out how many connections you will have at one time (MySQL makes quick connections. Don’t really need to make a persistent one, but likely won’t hurt)

Direct Query Execution using PDO

• Queries that modify information use the exec() method.
• Return value is the number of rows affected by the operation. Returns boolean FALSE on error (INSERT, UPDATE, DELETE).
• Queries that select information use the query() method.

Problems with direct queries

• Query needs to be interpreted on each execution. Can be a waste for frequently repeated queries.
• Security issues with un-escaped user input can lead to SQL injection.
• Escaping: quote() method. Handles special characters in PDO. Quote automatically adds single quotes to wrap the query: "SELECT * FROM USERS WHERE".quote($variable)." LIMIT 0,1"

Prepared statements

• Compile once and execute many times
• Separation between structure and input to prevents SQL injections
• Often faster than query()/exec() even for single runs.
• Uses wildcards/tokens to hold variables; those variables are handled as a parameter, making injection attacks much less likely (bound parameters)

Retrieving information using PDO

• Array (Numeric or associative)
• String (for single column result sets; ex: selecting an id from a user login table)
• Fetch into a class
• Objects
  • Ability to retrieve data into an object
  • Ability to retrieve data into an exisiting object
• Callback Function
• Lazy fetching
• Iterators

Result Iteration – Fastest way of retrieving data through PDO

$res=$db->query("select * from users",PDO::FETCH_ASSOC);
foreach($res as $row){
   // returns an associated array
}

Lazy fetches

• Lazy fetches results in a form object, but holds the populating properties until they are actually used.
• Prevents PHP from fetching the data until you use it.

Related links

• PDO Functions
• Prepared Statements and Bound Parameters (from an article about using ext/mysqli)

This is part three of my notes. This post may contain inaccuracies, typos, boo-boos, etc. Jay says his slides will be available on his web site, so be sure to check there as well. If you have questions, direct them to Jay or consult the MySQL documentation.

Benchmarking and Profiling tips

• Give yourself a target
• Record everything
• Isolate the problem (Shut down other programs. Stop network traffic to machine.)
• Get familiar with EXPLAIN as a means to optimize queries
• Optimize within reason. Makes more sense to speed up the 30 second query than the 1 second query.

Benchmarking Toolbox

• SysBench
• mysqlslap (MySQL version 5.1+)
• Apache bench
• Supersmack
• MyBench

Profiling: Diagnosing a running system to identify performance bottlenecks

Possible areas for bottlenecks:

• Identify performance bottlenecks
• SQL Coding and Index Usage
• Memory
• CPU
• I/O (Disk)

Profiling toolbox

• SHOW commands (SHOW PROCESSLIST, etc…)
• EXPLAIN and the Slow Query Log
• MyTop
• List of Linux Power tools (gprof/oprofile and vmstat.ps/top/mpstat/procinfo)
• apd for PHP developers

Jay Pipes is the Community Relations Manager, North America for MySQL, Inc. This was a three-hour tutorial about ways to fine-tune your MySQL queries.

This is part two of my notes. This post may contain inaccuracies, typos, boo-boos, etc. Jay says his slides will be available on his web site, so be sure to check there as well. If you have questions, direct them to Jay or consult the MySQL documentation.

Developing a database schema

• Use the smallest data type necessary
• Normalize your data; Denormalize only in extreme cases
• “Vertical partitioning”: Send to a different database based on the range of a key.
• Use ‘counter tables’ to mitigate query cache issues in InnoDB tables
• “Horizontal partitioning”: Split data into smaller tables. Put less-frequently accessed, less-frequently updated data in a separate table. Example: have separate tables for user logins and user addresses or interests.

Use indexes wisely

• Should have good selectivity (relative uniqueness of the index values to each other; there’s a way to calculate this)
• Look for ‘covering index’ opportunities
• On multi-column indexes, order is important
• As database grows, examine your index. Do you need to modify it?
• Remove redundant indexes for faster write performance. Don’t need more than one index on a field.

Coding tips

• Don’t think in a procedural programming style. Think about ‘sets’: you have two sets of data from which you need to retrieve data. How do you do this?
• Break queries into smaller units
• Use stored procedures (only available in MySQL 5.x)
• Learn to use JOINS effectively. Can often use a join instead of a subquery.
• When you use a function on an indexed function, the index will be ignored
• Use the ON DUPLICATE KEY UPDATE clause of the insert statement. No need to check first if the record exists then update or delete (Related: INSERT ON DUPLICATE KEY UPDATE and summary counters)
• TRUNCATE TABLE is typically faster than deleting records

Bulk loading performance

• Always use multi-record INSERT for mass bulk uploading
• Use ALTER TABLE … DISABLE KEYS syntax. It disables all indexes except for unique ones
• Use load data infile, or CSV storage engine (version 5.x only), then ALTER TABLE
• If loading into an InnoDB table, insert into a MyISAM table, then select from there into an InnoDB table
• To add or drop multiple indexes, use ALTER TABLE rather than multiple CREATE or DROP INDEX statements

Jay Pipes is the Community Relations Manager, North America for MySQL, Inc. This was a three-hour tutorial about ways to fine-tune your MySQL queries.

This is part one of my notes. This post may contain inaccuracies, typos, boo-boos, etc. Jay says his slides will be available on his web site, so be sure to check there as well. If you have questions, direct them to Jay or consult the MySQL documentation.

Indexes

• Gives you a sorted order that allows you to find things quickly.
• Indexes speed up select or read statements.
• Indexes slow down writing to the database because MySQL not only has to write the record, but also has to write the index.

The kind of indexes available and their efficiency depends on the type of storage engine you choose. Keep your indexes slim on write-intensive applications.

Types of storage engines

Choose your table’s storage engine type based on the type of information it holds, and the function for which you will use the table. Can mix table types in the same database.

MyISAM

• Unclustered data storage
• Good insert performance and good with concurrent inserts
• Small foot print
• B-tree, r-tree and FULLTEXT indexing; Can use for spatial calculations, such as ZIP codes
• Poor concurrent update and delete performance
• No foreign key support; You can use a foreign key, but relational integrity is not guaranteed. (Forthcoming in version 5.2)
• No transactions available

Good for warehousing data, logging data and auditing data.

InnoDB

Good for when you need a lot of concurrent updates and will be looking data up by ID. Good for online transaction processing.

• NO FULLTEXT indexing or spacial data (r-tree indexes).
• Large memory usage and a large data footprint.
• Full transactional support
• Support for foreign keys
• Be sure to set a primary key, and use the smallest possible key (INT not BIGINT). If you don’t InnoDB will create it’s own super-integer index. Because of the way InnoDB handles indexes, this is not desirable.

Archive

Good for archiving, audit logging, and distributable media (for example, applications that you don’t want the user to be able to modify).

• Quick inserts and table scans
• Read-only
• Zlib compression
• No indexes allowed
• No foreign key support

Memory / HEAP

Great for temporary tables, session data, calculation tables, or information that will be requested frequently.

• Very, very fast selects because it’s all stored in memory
• Supports hash or b-tree indexes
• Data is gone on reboot, but you can get around this with init_file or my.cnf/my.ini.
• Limited by amount of memory available on the server

Can combine engine types within the database to take advantage of each storage engine’s strengths.