sqlite и sqlite3 - разные библиотеки. Как mysql и mysqli.
SQLiteDatabase - это из sqlite, который умеет только старый sqlite 2.x. и потому не стоит использовать.
Используйте sqlite3 или pdo
нормально не умеет.
единственный костыль - собрать через большой подзапрос с union all нужные значения и через not exixts подзапрос выкинуть те что есть в таблице.
Я намеренно даже выделил never shrinks.
mysql никогда не обрезает этот файл. Не умеет. Перестроение таблицы каким-либо образом переместит данные в другое место внутри этого файла-tablespace или в другой файл при включенном per file, но файл этот уменьшить не может. Вообще. Штука очень древняя. https://bugs[dot]mysql[dot]com/bug.php?id=1341
Для btree - да, всё верно, индекс хранит копии индексируемых значений. Поэтому индексы занимают место, но и потому по btree можно сделать index only scan. Специфика кластеризованного innodb - во вторичные индексы всегда неявно входит ещё и значение первичного ключа.
keep all InnoDB tables and indexes inside the system tablespace, often causing this file to become very large. Because the system tablespace never shrinks, storage problems could arise if large amounts of temporary data were loaded and then deleted.
То есть два момента:
- в этом файле хранятся все таблицы и индексы созданные при выключенном innodb_file_per_table.
- mysql просто не умеет уменьшать этот файл
Насколько знаю, единственный выход - сдампить всё, удалить все innodb объекты, полностью стопнуть базу, удалить ibdata и ib_log, запустить базу и восстановить таблички. Ну или сдампить всё нужное и полностью переинициализировать инстанс.
Как именно он переиспользует свободное место - не знаю.
нет.
Подмасок должно быть фиксированное число.
Или регулярка, выхватывающая аттрибут id с дальнейшей обработкой до массива (explode, в частности)
Или один цикл. Но без регулярки, а пишете свой парсер строки на конечном автомате.
difight, во время которого из запусков скриптов?
Если не поняли, почему я спрашиваю именно так - вы просто не понимаете, как работает shared nothing архитектура PHP. Между разными запусками одного скрипта нет совершенно никакой связи. Кроме той, что запрограммируете самостоятельно.
Да, вы можете сделать unset($_POST); Он выполнится, удалит эту переменную, затем скрипт завершится, браузер пришлёт новый запрос, PHP инициализирует окружение заново. Почему здесь не должно быть $_POST, если клиент его прислал?
difight пишет:
а unset случайно не после header("Refresh:0"); вставляли ?
Кстати сюда тоже прокомментирую: не имеет значения. header не прерывает поток выполнения скрипта и как правило не будет отправлен клиенту до начала вывода страницы (или завершения скрипта).
Сделайте редирект как в 4 строке.
unset для любых $_POST, $_GET, $_COOKIE, $_SERVER делать бесполезно, их присылает клиент и если клиент их опять пришлёт - конечно они никуда не пропадут.
Ну и конечно же самый главный вопрос - а как можно более правильно написать код получения картинки? он является какбы рабочей лошадкой.
Повторюсь: зачем вам вовсе писать картинку в базу если заведомо известно что читать будут только последнюю?
Зачем вам вообще какой-то код для получения картинки?
Раздавать картинку напрямую файлом на порядок-другой дешевле чем из базы и ещё на пару порядков дешевле если не дёргать PHP. А та задача что вы пока что описали именно что не требует ни чтения базы ни даже вызова PHP для показа картинки.
clawham пишет:
По поводу persistent sqli я ничего не понял - просто вместо localhost надо написать p:localhost?
Согласно документации да. Редко mysqli вижу. В сравнении с PDO неудобный API для prepared statements.
clawham пишет:
а с данными - штук 400 датчиков раз в 3 секунды должны будут делать запрос как на передачу картинки только там будут числовые данные и вот эти данные надо складировать в базу данных а потом опять же выдавать в графики и прочее и там уже рабочей лошадкой будет загрузка данных на сервер. и тоже надо как-то красиво это делать чтоб не насиловать sql
Начать с того, что реляционная база вообще не очень подходящий выбор для откровенно time-series данных, для которых есть специальные time series database.
400 датчиков по 3 секунды, 4млрд событий в год. Ну такое. Пробовали сгенерировать фиктивных данных за пару месяцев? Для начинающего 350млн строк в месяц и попытка представить выборку из них на графике могут оказаться сюрпризом. Сильно зависит от того как именно строить графики, впрочем.
clawham пишет:
почему отдельно выделил платные? да потому что даже если взять самый дорогой план на https://thehost[dot]ua - то там всего 36000 соединений максимум... это ж всего 10 клиентов с обновлением раз в секунду наклоцать могут! Как не на нем порталы целые предлагается хостить с 10-ком сайтов?
А что, вот это - единственный вариант?
Ну хрень какая-то. Дешёвая. 7 долларов в месяц всего. Да даже топовый сервер всего на 32гб ram и с 4 ядрами предлагают. Что за ужас там ставят вместо SSD боюсь представлять. В общем компания явно специализируется на низкобюджетных клиентах с визитками и другой мелочёвкой. Что с другой стороны тоже неплохо, лучше чем пытаться угодить всем и не угодить никому в итоге.
Кому надо что-то приличнее - пойдут к другим. Лично мне привычна картина из нескольких серверов на 100-200ГБ RAM и нескольких десятков ядер CPU только под нужды базы обслуживающей всего один сайт.
Вот отсюда - зачем?
Пишите в файл и раздавайте файлом.
В остальном:
По коду - вы поразительным образом умудрились совместить prepared statements и sql инъекции. Не надо так делать. Посмотрите примеры даже в документации, как передавать параметры для запроса.
clawham пишет:
я каждый раз открываю новое подключение.
Верно
clawham пишет:
есть какие-то глобальные переменные которые от запуска к запуску скрипта сохраняют свое значение?
Переменных нет. PHP намеренно сделан shared nothing
Но некоторые вещи бывают разделяемые, в частности mysqli можно попросить держать persistent connect: http://php.net/manual/en/mysqli.persistconns.php
clawham пишет:
Во всех хостингах даже платных кол-во подключений к базе данных ограничено.
Очень странно выделили "даже платных".
Не во всех, конечно. Возьмите банально VPS и подключайтесь к mysql так часто насколько у вас хватит ресурсов CPU.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 11869
