如何使用 PHP 从 MySQL 数据库中存储和检索图像？

Question

How can I insert an image in MySQL and then retrieve it using PHP?

I have limited experience in either area, and I could use a little code to get me started in figuring this out.

Answer 1

First you create a MySQL table to store images, like for example:

create table testblob (
    image_id        tinyint(3)  not null default '0',
    image_type      varchar(25) not null default '',
    image           blob        not null,
    image_size      varchar(25) not null default '',
    image_ctgy      varchar(25) not null default '',
    image_name      varchar(50) not null default ''
);

Then you can write an image to the database like:

/***
 * All of the below MySQL_ commands can be easily
 * translated to MySQLi_ with the additions as commented
 ***/ 
$imgData = file_get_contents($filename);
$size = getimagesize($filename);
mysql_connect("localhost", "$username", "$password");
mysql_select_db ("$dbname");
// mysqli 
// $link = mysqli_connect("localhost", $username, $password,$dbname); 
$sql = sprintf("INSERT INTO testblob
    (image_type, image, image_size, image_name)
    VALUES
    ('%s', '%s', '%d', '%s')",
    /***
     * For all mysqli_ functions below, the syntax is:
     * mysqli_whartever($link, $functionContents); 
     ***/
    mysql_real_escape_string($size['mime']),
    mysql_real_escape_string($imgData),
    $size[3],
    mysql_real_escape_string($_FILES['userfile']['name'])
    );
mysql_query($sql);

You can display an image from the database in a web page with:

$link = mysql_connect("localhost", "username", "password");
mysql_select_db("testblob");
$sql = "SELECT image FROM testblob WHERE image_id=0";
$result = mysql_query("$sql");
header("Content-type: image/jpeg");
echo mysql_result($result, 0);
mysql_close($link);

Answer 2

不是将图像存储在数据库中，而是将它们存储在磁盘中的文件夹中，并将它们的位置存储在数据库中。

Answer 3

Beware that serving images from DB is usually much, much much slower than serving them from disk.

You'll be starting a PHP process, opening a DB connection, having the DB read image data from the same disk and RAM for cache as filesystem would, transferring it over few sockets and buffers and then pushing out via PHP, which by default makes it non-cacheable and adds overhead of chunked HTTP encoding.

OTOH modern web servers can serve images with just few optimized kernel calls (memory-mapped file and that memory area passed to TCP stack), so that they don't even copy memory around and there's almost no overhead.

That's a difference between being able to serve 20 or 2000 images in parallel on one machine.

So don't do it unless you absolutely need transactional integrity (and actually even that can be done with just image metadata in DB and filesystem cleanup routines) and know how to improve PHP's handling of HTTP to be suitable for images.

Answer 4

My opinion is, Instead of storing images directly to the database, It is recommended to store the image location in the database. As we compare both options, Storing images in the database is safe for security purpose. Disadvantage are

1. If database is corrupted, no way to retrieve.

2. Retrieving image files from db is slow when compare to other option.

On the other hand, storing image file location in db will have following advantages.

1. It is easy to retrieve.

2. If more than one images are stored, we can easily retrieve image information.

Answer 5

我还建议您考虑这一点，然后选择将图像存储在您的文件系统而不是 DB 中。请参见此处： 在 DB 中存储图像 - 是还是不是？

Answer 6

Personally i wouldnt store the image in the database, Instead put it in a folder not accessable from outside, and use the database for keeping track of its location. keeps database size down and you can just include it by using PHP. There would be no way without PHP to access that image then

Answer 7

不要将图像存储在数据库中，而是将其存储在您的手机和电脑中，然后使用它的路径，因为它将保存您的数据库

Answer 8

I agree with the basic concept of @Andomar, but would store the actual images on disk to avoid storing large data in SQL. Remember that a large field is 255 chars in SQL. So you'll need to store the images files in Blobs, which work well when you only have a small amount rows (think: hundreds, not millions). The reasoning is complex, but it's good practice. Here's how I know:

I wrote a large project that stores lots (and lots) of images. Always store them on disk to save yourself a SQL headache. If you're worried about a DB corruption leaving you with images you can't "rebuild" into a database, there's an easy fix (besides backing up your SQL table(s) )

Store your images in a directory tree with directory names that make sense for humans and parsing. So storing it by time might look like "/year/month/day/picture.jpg" or by user "/user_id/picture.jpg". Use this as a concept, and just store the path in SQL. This will make your SQL table small and often cacheable and allow your SQL table to be on one server, and your images to be stored on another "server" such as AWS's S3.

If you're really paranoid, you can store a file called "{image_name)_meta.json" in the same directory as the image itself. Fill it with meta data about the image that you normally store in the DB table. If the table corrupts, you can write aa little function that walks through the tree and rebuilds the table from the JSON files. This of course will take up more disk space, but it's pretty cheap (think: AWS's S3).

There are lots of ways to solve this, but storing large amounts of images in any SQL-type table is rarely a good idea. Exceptions would be displaying hundreds at once, or perhaps lighting-quick retrieval times (instead of sub-second).

Good luck with your project!