IF YOU ARE USING INNODB:
If you are using INNODB, since you verified the row was inserted, it should have been
returned with the SELECT, as long as the SELECT was querying the key of the actual row
that was inserted. (Are you sure you aren't using a feature like INSERT DELAYED? That
could prevent the row from being returned.)
IF YOU ARE USING MYISAM:
Since MyISAM doesn't support transactions, the SELECT should return the insert, but I
cannot find anything that states this is actually guaranteed.
NOTE: The first URL listed below states if you are using MYISAM (the default according to this link),
INSERTS will lock the table. However, the second URL states that the lock placed by an insert is a readable lock, so that should not have prevented the table from being read.
http://www.sitepoint.com/mysql-mistakes-php-developers/
http://aarklondatabasetrivia.blogspot.com/2009/04/how-to-lock-and-unlock-tables-in-mysql.html
IF YOU ARE USING INNODB (CONTINUED):
If AUTOCOMMIT is in use in your system (I am not sure) you should have seen
the selected row (this question states the row inserted was verified as having
been added to the database).
If a transaction is in use, the transaction must have been committed (this question
states the row inserted was verified as having been added to the database).
Are you sure the SELECT query that is executed the first time is the same
as the one the second time?
Are you sure $user['social_id']
is the same value after the
INSERT and at the time of the SELECT?
If, for some reason, you are using INSERT DELAYED, the row may not be returned
NOTES:
According to this URL, IF you have started a transaction, the selected rows
are shown in the next SELECT statement (not in PHP):
http://zetcode.com/databases/mysqltutorial/transactions/
This statement implies that if you begin a transaction, you don't need to
set AUTOCOMMIT:
"MySQL also automatically commits statements that are not part of a transaction."
This URL describes how to start a transaction in PHP:
PHP + MySQL transactions examples