Intereting Posts
Выберите несколько вариантов в пользовательской мета-форме WordPress Изменение get_author_posts_url () в Multisite Пользовательский тип сообщения, не отображающий содержимое с одной страницы {custom post type} Неверная дата, возвращенная get_the_time Как отобразить alt теги в img src? Я хочу добавить параметр URL ко всем URL-адресам Динамически добавлять подкатегории в любую категорию в меню перемещающийся сервер не может войти Скрыть метабокс в зависимости от выбранного шаблона страницы Отобразить первый тег, назначенный сообщению Как удалить все следы плагина? Pagination не работает должным образом для архива настраиваемого типа сообщений, указанного на первой странице WP_Query с пользовательским типом поиска постов, показывающим все результаты каждый раз WordPress отбрасывает обратную косую черту из HTML Требовать от пользователя ввода кода из массива разрешенных кодов с помощью Gravity Forms

Сбросить / изменить порядок сообщений в таблице MySQL wp_posts

У меня очень популярный сайт WordPress. Я занимаюсь оптимизацией сайта перед добавлением других плагинов, таких как плагин WPML, который, как я подозреваю, будет использовать пользовательские типы сообщений. На сайте уже есть другие плагины, которые я не подозреваю, использую таблицу wp_posts для пользовательских типов сообщений, за исключением 1 или 2, которые нужно создать.

Возможно ли перестроить / обновить / изменить порядок столбца идентификатора в таблице wp_posts, чтобы идентификаторы сообщений начинались с 1 и увеличивались без каких-либо пробелов.

Таблица wp_posts содержит 3 349 строк. На сайте содержится около 412 сообщений (тип сообщения) в таблице wordpress wp_posts. Наибольшее количество в столбце ID – 7060 (это очень большое), и любое добавленное новое сообщение увеличит число до 7061. Остальные строки в таблице представляют собой другие типы сообщений, такие как вложения, некоторые из которых были созданы старыми плагины. Есть 2786 строк для типа сообщения вложений, который очень большой, учитывая, что я больше не буду использовать эти вложения. В 412 сообщениях содержится вся информация, необходимая для сайта. Я конвертирую изображения в встроенный SVG и латекс. Большинство изображений были номерами. Так что после всего этого у меня, вероятно, будет 412 строк в таблице wp_posts.

Я знаю, что я могу сбросить AUTO_INCREMENT до 1, используя; ALTER TABLE tablename AUTO_INCREMENT = значение;
Но я не уверен, как изменить порядок почтовых идентификаторов. Я хочу узнать, какие меры предосторожности мне следует знать, прежде чем пытаться это сделать. Я думаю, что это важно для упрощения идентификаторов сообщений, потому что они будут использоваться по всему сайту Multi. Если есть решение, которое может переупорядочить и обновить все ссылки на сообщения в других таблицах, это было бы замечательно !.

Я знаю, что это функция MySQL, и мне придется работать с AUTO_INCREMENT.

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

Я, вероятно, потеряю теги и категории, но очень важно упростить идентификаторы сообщений. В любом случае, я буду перестраивать теги и категории. Есть ли опрятный способ держать эти прилипшие.

Есть ли другие опасения, о которых я должен беспокоиться? Поскольку на главных страницах сайта будет создано множество сценариев / функций, я хочу, чтобы идентификаторы сообщений были как можно более уникальными на данный момент. Наличие пробела в 100 секунд для меня не уникально.

Надеюсь, у кого-то есть идеальное решение для этого. Я пытаюсь сделать очень опасную идею?

Если вам нужны порядковые номера для ваших сообщений, не используйте столбец идентификатора сообщения.

AUTO_INCREMENT предназначен для предоставления уникальных номеров (и разделенных мозгов в репликации с несколькими мастерами), он никогда не будет иметь пробелов, особенно не в WordPress (ревизии, автосохранения, страницы, контактные формы, галереи и куча других плагинов) и особенно не с InnoDB. Простой сбой транзакции / откат может привести к тому, что поля AUTO_INCREMENT будут увеличиваться в миллиард раз, не вставляя одну строку, это довольно нормальное поведение. Я также процитирую Tamas из этого потока переполнения стека:

Вы никогда не должны зависеть от числовых функций автогенерированных ключей.

С точки зрения производительности это не имеет большого значения. BIGINT холдинг 412, холдинг BIGINT 7060 и BIGINT владеющий пятью миллиардами, являются 64-битными целыми числами.

Если вам нужны поистине последовательные идентификаторы (для вашего UX или что-то еще), вы должны использовать свою гораздо более предсказуемую и изолированную логику нумерации.

Этот идентификатор сообщения используется для сшивания данных по многим различным таблицам с помощью WordPress Core, плюс любые плагины, которые могут сделать или что бы тема не могла сделать. Также существует вероятность разрыва ссылок, если ваш сайт когда-либо использовался ?p= permalinks. Так что да, это очень опасная идея.

Чтобы правильно сбросить идентификаторы сообщений, вам предстоит много работать, но эта работа будет потрачена впустую. WordPress использует неподписанный BIGINT для этого поля, который может иметь верхний предел 18 446 744 073 709 551 615 . Вы никогда не доберетесь туда, с или без «пробелов» между сообщениями.

Кроме того, каждый раз, когда WordPress делает запись в базе данных, вам придется переделать работу, так как WordPress не прилагает никаких усилий, чтобы сохранить идентификаторы в порядке, поскольку вы, кажется, ошибочно думаете, что это необходимо. Поэтому каждый раз, когда WordPress изменяет базу данных, вы собираетесь ее очистить. Это много кода для написания, чтобы поставить систему на место и много времени процессора для ее запуска.

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

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