nokimaro

SELECT user_id FROM table WHERE star_count = '454'

Так как стоит тег MySQL предполагаю что ссылки хранятся в базе?
Значит для каждой ссылки нужно сделать колонку со временем создания ссылки и временем первого клика (захода) по ней.
Время создания ссылки можно использовать если надо в принципе ограничить ссылку по времени, независимо от того посещали её или нет.
Время захода по умолчанию null. При открытии ссылки смотрим это значение, при первом заходе заполняем текущую дату, при повторных кликах сравниваем дату и текущее время.
Если прошло больше определённого времени считаем что ссылка удалена.
Так же можно фактически удалять из базы ссылки с истёкшей датой, при этом ссылки где дата посещения null считаем не посещёнными и не удаляем. Это уже зависит от ваших требований.

Если данные побились при переносе, то смена кодировки пост-фактум может не помочь.
1. Нужно проверить содержимое дампа. Так как может быть проблема в том как сохранены данные там.
2. Перезалить дамп по новой

Если у вас, предположим таблица была в latin или cp1251 в старой базе, вы сделали дамп. Он тоже в latin. Заливаете в новую базу которая настроена на utf8, то корректно дамп не зальётся никогда.

Не хватает информации по исходным данным. Но для случая если данные были в 1251 и сейчас хотим utf8 то содержимое дампа можно переконвертить через iconv или enconv

Вариант без placeholder'ов, если $ids массив из INT'ов то можно прогнать каждый элемент через intval() чтобы исключить любого рода инъекции и напрямую подставить в запрос

$ids = array_map('intval', $ids);
return $this->db->row("SELECT * FROM cources WHERE id IN (".join(',', $ids).")");

Нет никакой волшебной пули. Если есть такая задача, то только хранить списки просмотренных постов по каждому пользователю вида user_id, post_id
И при построении ленты соотв-но исключать из выборки то что "не нужно" или через JOIN или через подзапрос вида NOT IN (...)
В данном случае грамотные индексы и наличие достаточного кол-ва RAM на сервер должны решать большинство проблем производительности.
Так же, возможно, сейчас разговор о преждевременной оптимизации, так как действительно ли будут сотни тысяч постов которые просмотрит один пользователь? Ведь это колоссальный объём который кто-то ещё должен запостить.
Как вариант оптимизации, на будущее, можно историю "просмотренных постов" подчищать, удаляя там записи старее такой-то даты или чистить по кол-ву.
То есть хранить историю просмотров "за месяц" или хранить последние 1000-10000 просмотренных постов каждым пользователем, что уже не такие большие числа.

<?php
$last_view = $model -> query("SELECT * FROM `w3m_404urls` WHERE `views` >= 3");
while($row = $last_view->fetch_assoc())
{
    echo "<tr>
        <td>{$row['id']}</td>
        <td>{$row['url']}</td>
        <td>{$row['date']}</td>
        <td>{$row['view']}</td>
    </tr>";
}

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