hrvasiliy: Похоже, у вас бардак с добавлением статьи - при добавлении локазированного варианта страницы CMS не знает, какая это страница в оригинале. В таком случае предложенный вами вариант будет работать ровно до того момента, пока при добавлении локализированного варианта контент-менеджер не додумается поменять картинку. Я правильно понимаю?
stamdyscias: ну он же не может скачивать в никуда, имя файла, куда складывать, все равно нужно. Генерируйте случайные имена, с использованием uniqid() (php.net/manual/en/function.uniqid.php), например, и складывайте в специально обученную директорию.
Вы можете упереться в верхний предел INT (или BIGINT) и тогда INSERT будет генерировать ошибку. Впрочем, верхний предел BIGINT UNSIGNED - 18446744073709551615.
Если сервер ваш, или его обслуживает ваш DBA, можно увеличить max_allowed_packet (максимальный размер - 1GB). Если же нет, то да, надо будет считывать по частям. Либо вы заранее складываете не в один файл, в в несколько, скажем, по 1000 строк. Однако, я повторюсь: CSV в 16 MB - это реально очень много.
astrotrain: Нет, не нужны. Это самый быстрый из всех возможных способов вставки большого объема данных в таблицу. Более того, он очень гибкий - их можно преобразовывать еще при этом, или писать не все столбцы из источника, например. Значение max_allowed_packet по умолчанию - 16MB, это очень много на самом деле. Количиство записей при этом не ограничено.
Подготовленные выражения. Вы составляете запрос, в нем вместо готовых параметров пишете плейсхолдеры. Затем с помощью указанного выше bind param назначаете значения, которые будут переданы на эти плейсхолдеры. Основные преимущества такого подхода таковы: 1. sql сервер кэширует запрос и составленый execution plan (вычисление оного в принципе трудоемкая и сложная для сервера операция), и просто каждый раз подставляет параметры - это очень позитивно сказывает на производительности. 2. Поскольку на sql сервер запрос и параметры передаются отдельно, возможность sql инъекции (и совершенно нормальных одиночных кавычек в в строках, привет от О'Хары) полностью исключена. По ссылке выше в разделе Example #2 Procedural style указан пример использования в процедурном стиле, то есть как вы указали в примере.
Вы совершили архитектурную ошибку, собрав связи contacts с user_apps и apps в одной таблице - это разные вещи по сути. Попробуйте вынести связи в отдельные таблицы, и через них JOINить.
Дмитрий Масленников: Я понял, в первом случае table scan, потому что в where у вас некалстерный индекс, а во втором случае вообще CROSS JOIN. Попробуйте переделать второый запрос следующим образом:
SELECT b.post_id, b.owner_id, b.content_text, b.location_name, b.provider_id, b.provider_source_id, b.provider_source_id_full, b.provider_source_domain, b.provider_source_link, b.provider_source_name, b.provider_source_photo, b.provider_post_link, b.attachment_0_photo, b.created
FROM (
SELECT post_id
FROM user_posts
WHERE owner_id='30'
ORDER BY created DESC
LIMIT 20
) as a inner join user_posts as b on b.post_id=a.post_id;
Demetriy, nepster09: Это нужно сделать SET TRANSACTION ISOLATION LEVEL SERIALIZABLE. А чтобы mysql ничего не обрезал по тихому, надо еще сделать SET @@sql_mode = 'TRADITONAL', то есть включить так называемый strict mode. Проверьте, чтобы движок был Innodb (мало ли) и повысьте уровень изоляции транзакций.
