FanatPHP

Отучайся задавать вопросы по мелким техническим деталям, в которых ты запутался.
Спрашивай сразу про основную задачу, чтобы тебе объяснили, как ее делать ПРАВИЛЬНО.

"я получаю по одной строке из бд" - ЗАЧЕМ?
"запросом выше я хочу узнать, а последняя ли" - зачем?

Первое, что надо узнать - ЗАЧЕМ тебе это нужно - " делать автоинкремент только тогда, когда он добавил реально запись"? Какая тебе разница, какое значение у этого поля?

Отвечать подробно

Неправильно.
Правильно будет так:
1. пишем в адресной строке браузера mysqli_fetch_assoc
2. В открывшемся окне переходим по первой ссылке
3. Внимательно читаем.
4. Думаем.
5. Смотрим примеры.
6. Пишем правильный код.

Ответов на вопрос в заголовке ты получишь с десяток (покольку средний посетитель сайта тостер ру не в состоянии осилить текст размером больше предложения), так что на нем я останавливаться не буду.

Если же отвечать на вопрос в теле поста, то беги от обоих как от чумы. Оба "языка" - доморощенные поделки, которые будут висеть как гири на руках и ногах, не давая развиваться и следовать за современной программистской мыслью.

Тот же похапе, правильно приготовленный, не вызывает никакого отторжения - а все потому, что со времен говнокода из прошлого века, которому тебя учили в институте, развитие языков шагнуло далеко вперёд. Ни один из популярных язвков не остался в стороне - все получили новые фичи, у всех поменялся подход к разработке, для всех появились современные фреймворки, все следуют современным течениям и идеям. Благодаря тому, что все эти языки развиваются сообществом по всему миру.

Здесь же ты должна понимать, что работая в ПэЛэ-Плюс, ты работаешь не с БД, и даже не с индустриальным стандартом PL/SQL, а с "проблемно-ориентированной" кустарной подделкой. 1С:Битрикс же среди разработчиков и вовсе давно уже является ругательством. Но главная проблема не в этом. А в том, что оба инструмента обречены на стагнацию и умирание. Садиться на проприетарные средства разработки в век открытого программного обеспечения - это хоронить себя заживо. Какой бы уникальной ни была разработка, оставаясь в руках единственной организации, она будет чудовищно отставать в развитии и вместе с собой тормозить разработчиков.

Так что, если говорить о перечисленных технологиях, то берись за любую работу, лишь бы она заключалась в использовании css и javascript. Не потому что они интереснее (для клиентской разработки нужно иметь особый склад ума, склоняющийся к визуальному творчеству), но потому что это стандартные средства, по которым ты всегда можешь получить помощь всемирного сообщества и на которых всегда найдешь работу.

Дла начала надо понять, что никакой живой пользователь никогда не будет читать 20 000 записей на одной странице.

после этого можно продолжать оптимизацию

Как всегда - дурацкий вопрос, да еще и по-дурацки сформулированный, порождает кучу дурацких ответов.

ЕСЛИ не читать тело вопроса, а отвечать на вопрос из заголовка (а это ключевой момент для Q&A сайта, поскольку тупые поисковики приводят именно по заголовкам. И администрация должна следить за релевантностью оных и вычищать вопросы, которые автор не в состоянии сформулировать), то ответ однозначный - за выборку ЗАПИСЕЙ только для того, чтобы ПОСЧИТАТЬ их, дают пожизненный эцих с гвоздями. Считать должна база!

ЕСЛИ отвечать на вопрос вне контекста вставки, а только глядя на запросы, то ответ - ОДИНАКОВО. В обоих случаях никакого подсчета нет а есть только выборка по ключу.

ЕСЛИ вникать в контекст задачи чуть глубже, то появляются варианты ускорить МНОЖЕСТВЕННУЮ проверку, такие как prepared statements (тот редкий случай, когда их фича с множественным исполнением может выстрелить).

ЕСЛИ вникать в задачу окончательно, то правильным будет ответ @zeromodule. Причем вставку надо либо делать множественную, по тысяче записей, либо заворачивать в транзакцию - поскольку ОБНОВЛЕНИЕ ИНДЕКСА при таком количестве вставок начнет тормозить работу куда сильнее, чем нищасные селекты, столь пугающие аффтара. И опять же использовпать prepared statements.

форму с кнопкой отправить делать не хочу,

Хотелки и капризульки оставляем дома. После этого вооружаемся знаниями и технологиями.

Подсказываю:
Смотреть в сторону стандартной формы, с перезагрузкой. Чтобы получить хотя бы отдаленное представление о том, что ты делаешь и с какой технологией работаешь.

После того как ты освоишь стандартный вариант с презагрузкой, и он, наконец, заработает - можешь попробовать освоить технологию AJAX для того чтобы сделать без перезагрузки.

Учитывая, что цифра совершенно бессмысленная, проще всего будет сделать
echo rand(10, 15);

Суть, на самом деле, в том, что

Первое: портируя свой код с "процедурной модели" на "объектно-ориентированную" аффтар умудрился не заметить цикл, который был в первой, но испарился во второй. Но виновата оказалась модель ООП РНР.

Второе и самое главное: портируя свой старый говнокод с mysql_* аффтар осилил только добавление буковки i и стрелочек, всё остальное оставив как есть. Получив в итоге ровно тот же самый говнокод, что и раньше.

Для справки:
Смысл перехода с mysql на mysqli не в том, чтобы добавить палочку с точечкой. А в том, чтобы использовать подготовленные выражения.
Смысл ООП не в том, чтобы писать палочки с угловой скобочкой. А в том, чтобы объект инкапуслировал внутри себя всю работу по обработке данных, возвращая сразу желаемый результат. В итоге код, реально использующий ООП, должен выглядеть как-то так:

$sql = "SELECT `service` FROM `service_synonyms` WHERE `synonym` LIKE ?";
$result = $this->_dbconn->getAll($sql, "%$query%");

Вообще, вопрос звучит довольно странно. "Можно ли применять автомобиль для езды?" "Годятся ли деньги для оплаты товаров?", "Безопасны ли подготовленные выражения с точки зрения защиты от инъекций?".
Собственно, если это их основное предназначение - то наверное, не обеспечивай они защиту, то были бы бесполезны чуть более, чем полностью?

Смысл подготовленных выражений в том, чтобы решить 3 задачи при формировании динамического запроса:
1. чтобы вставляемый в запрос литерал был отформатирован корректно
2. Чтобы форматирование было обязательным
3. Чтобы оно производилось как можно ближе к фактическому исполнению запроса.

Благодаря этим трем пунктам обеспечивается гарантированная защита даже с учетом человеческого фактора.

Так что да - если ЛЮБАЯ переменная попадает в запрос только через плейсхолдер - этот запрос безопасен. Другое дело, что в реальной жизни так не выходит, и переменные в запрос добавлять приходится. Как поступать в таких случаях, я описал в специальной статье

Ну и напоследок стоит упомянуть о том, что режимов работы у ПДО два: "настоящие" подготовленные выражения и эмуляция. В первом случае запрос исполняется в два этапа - сначала отправляется на серевер БД запрос с плейсхолдерами (знаками вопроса), а потом, следующим пакетом - данные для него. Этот режим также удобен если нам надо выполнить много однотипных запросов, позволяя сэкономить пару наносекунд. По умолчанию же ПДО только эмулирует этот режим, отправляя запрос в одну ходку, подставляя значения прямо в запрос. Но поскольку он форматирует их корректно, то никакой опасности опять же нету

Ну и под конец можно упомянуть редчайший случай, раздуваемый истеричками типа Шифлетта или Феррары - если вы китаец, и используете кодировку GBK (или одну из пары других, столько же часто используемых), то надо не забыть выставить кодировку соединения именно в DSN и только в DSN. Потому что если использовать по привычке SET NAMES, то в режиме эмуляции инъекция будет возможна. То есть, ситуация, когда инъекция через ? плейсхолдер возможна - она существует. Но для этого должны совпасть три фактора:
- вы должны быть китайцем и использовать кодировку GBK
- кодировка должна быть задана не в DSN
- режим эмуляции должен быть включён

если данные атрибутов находятся сериализованные в базе в таблице option,

Взять рельсу, и долго с наслаждением бить по голове того, кто стал хранить данные атрибутов сериализованные в базе в таблице option. Потом добавить по почкам.

Потом перепроектировать базу.
Сделать категории в нормальной таблице, приджойнить к запросу и сортировать по ним.

В первом варианте ничего «обычного» нет. Это вообще не вариант.
Если у нас действительно key-value хранилище, без вложенности и древовидности, то вполне подойдет второй.
Проблем с «контролем на чтение-запись» никаких не вижу. Уникальный ключ на юзер_айди-парам_айди должен решить все проблемы.

А вот если система должна поддерживать иерархию — к примеру, категория «хобби», к которой могут относиться сотни различных занятий — то как раз предложенная выше Монга и объединяет в себе эти два, на первый взгляд, противоречивые требования — хранение в JSON плюс выборки и сортировки.

Следует только учитывать особенности этой БД, являющиеся следствием её достоинств — поскольку у базы нет четкой структуры, то обязательно нужно хранить мета-информацию самостоятельно — поддерживать вручную список всех имеющихся в записях полей.